title: Do you know the SharePoint 2016 "Zombie ItemID Cache Bug"?
body: <p>After migrating various SharePoint 2013 JavaScript apps to SharePoint 2016, I had to look at an strange phenomenon of the SharePoint 2016 Rest API:</p>
  
  <p>assume you have 2 ajax calls</p>
  
  <ol>
  <li>Upload a file --> returns spFile</li>
  <li><p>get the list item for the uploaded file --> returns spItem</p>
  
  <pre><code>jQuery.ajax({
      url: "/sites/mysite/_api/web/getFolderByServerRelativeUrl('/sites/mySite/myLibrary')/files/add(overwrite=true, url='test1.txt')",
      type: "POST",
      data: params.arraybuffer,
      processData: false,
      headers: { "Accept": "application/json;odata=verbose", "X-RequestDigest": params.digest, "X-HTTP-Method": "POST","If-Match": "*" },
      success: function (file) {
          //get listItem for uploaded file
          jQuery.ajax({
              url: file.d.ListItemAllFields.__deferred.uri,
              type: "GET",
              headers: { "accept": "application/json;odata=verbose" },
              success: function (result) {
                  //after first upload: OK
                  var id = result.d.ID;
              }
          });
      }
  });
  </code></pre></li>
  </ol>
  
  <p>If the file has not yet existed under this URL, everything is OK. SharePoint creates a new list item, and you will get the new item with the correct ID in the second call - lets assume we get ID 1.</p>
  
  <p>If a file with the same name was already existing under this url and later it was deleted, SharePoint generates a new item with a new ID. This is as expected. 
  BUT: In this case, the SharePoint Rest API returns the wrong list item. Instead of the new created list item (ID 2), you will get the old deleted item with ID 1.</p>
  
  <p>In SharePoint 2013, this error does not occur. In SharePoint 2016 - this error only occurs in case of the same browser context for ajax call 1 and ajax call 2. Typically you are affected by this error, if you upload a file und at the same time you will update some meta values.</p>
  
  <p>It seems to be a bug in SharePoint 2016. I suppose, MS have implemented a more strictly cache algorithm and was getting over the target. </p>