This is perhaps one of the most bizarre problems/bugs I’ve ever seen with SharePoint. And, to be clear, I am only seeing it with one user (so far!), specifically using Edge (v.85.0.564.44). If I have the same user use their Chrome or Firefox browser, everything works as expected. I also have the same version of Edge on my laptop, and when I try using Edge on the same page to execute the same code, everything works as expected. So it definitely seems to be a very isolated issue, and I realize that because of that this is getting very close to being off-topic here.
But at the same time, the issue is that what seems to be a very straighforward REST query is showing bizarre results returned from the server, so it leads me to believe that something is going on with the request somehow that is causing the server to respond the way it does, so in that respect this is a question about the correct way to interact with the SharePoint REST API, and therefore on-topic.
Anyway, what is happening is… well, let me set up a very contrived, simple scenario to make it easy to illustrate what I’m seeing.
Imagine a list set up like so, which includes a multi-select lookup field:
ID Title AMultiLookup
-- ---------------- ------------
1 I am Number One! (1, 2, 3)
2 It should be me (4, 5, 6)
3 The third one (7, 8, 9)
(I’ve used the lookup IDs set in the lookup field to make it easier to see what’s happening.)
Now imagine that I send a simple REST request for item with ID 2, using the endpoint
/_api/web/lists/getbytitle('My List')/items(2)
with no additional oData query parameters – no $select, no $filter, nothing – just straight up “give me item number 2”.
Given the list data above, I would expect a result of
d: {
AMultiLookup: {
results: (4, 5, 6),
},
ID: 2,
Id: 2,
Title: "It should be me"
}
However, what actually gets returned is
d: {
AMultiLookup: {
results: (7, 8, 9),
},
ID: 2,
Id: 2,
Title: "I am Number One!"
}
Notice that although the ID in the response is the ID of the item I asked for (2), the value of the Title field is from item ID: 1 and the value of the AMultiLookup field is from item ID: 3.
What the what??? How is that possible?
I first saw this issue in another query on another page where I was applying some $select values to limit the response (so ID was not included), and I thought perhaps it was an “off by one” issue where somehow the browser was incrementing (or decrementing) the ID of the item I was querying for before the request got sent out, so therefore the server was returning the correct result, it was just my query that was messed up. But in all cases, I construct the URL like
var uri = _spPageContextInfo.webAbsoluteUrl + "/_api/web/lists/getbytitle('List Name')/items(" + desiredItemID + ")";
$.ajax({
url: uri,
// etc
});
and I set breakpoints after the uri string was constructed, but before the request went out, and saw that the string did include the correct item ID being requested. The fact that the ID of the requested item was not being changed was borne out by the results of the request that did not add any $select parameters and returned the ID of the item in the result, which matched what was being requested.
Also, I don’t think it’s an “off by one” browser mutation kind of error being applied to the results after they’re received, because
- How could the browser change the string of the
Title property to exactly what the Title is of a different list item?
- The lookup IDs in the multi-lookup array were not “off by one”. It the expected result was
(4,5,6) the actual result was not (5,6,7), it was (7,8,9). And in any case, in the actual data, the expected result was not in numerical order (i.e. the true expected result was (4,6,5)), while the actual result was in numerical order, which perfectly matched the value of the field in the other list item.
So I think there is compelling evidence here that a request for a single list item (by ID) is returning data from adjacent list items on both sides of the requested item.
So…. how does that happen?
I’m using jQuery 3.4.1 to make the requests, and I’m not doing anything fancy with the requests, they’re super basic, like
$.ajax({
url: uri,
method: 'GET',
headers: {
accept: 'application/json;odata=verbose'
}
});
Could Edge be adding some extra header that confuses the server and causes that behavior? If so, it’s not inherent in Edge v.85.0.564.44, since I also have that version and it behaves fine for me.
Any ideas here would be appreciated.