412 Precondition Failed
Situations in the vault where SharePoint, SPFx, Microsoft Graph or the Azure services around them answer with HTTP 412. Each one explains why it happens and how to fix it.
- A status code measures where the request stopped first, not what the user may dogotchas / permissionsA probe that writes with a deliberately stale IF-MATCH and reads permissions off 403 vs 412 measures which gate the request hit first: SharePoint evaluates the etag BEFORE authorisation, so 412 comes back even where…
- Adding an attachment changes the item's ETag – the next MERGE with the old ETag fails with 412gotchas / rest-apiAttachmentFiles/add changes the item ETag; re-read before an IF-MATCH update
- Two MERGEs to the same list item at once: the second one fails with 409 Save Conflict even with IF-MATCH: * – and a fire-and-forget write just disappearsgotchas / rest-apiIF-MATCH: * only switches off the ETag check (412); SharePoint still refuses a second save of the same item while the first is in flight with 409 Save Conflict. Queue writes per item (list#id), retry 409 briefly, never…
- The ETag key is @odata.etag in OData v4 – reading odata.etag silently turns IF-MATCH into *gotchas / rest-apiSPHttpClient speaks OData v4: the item ETag comes as @odata.etag; reading odata.etag yields undefined and your IF-MATCH protection quietly disappears