How to handle concurrency
Update a Management resource without silently overwriting someone else's change.
The pattern
read -> keep the ETag
apply -> send it back in If-Match
412 -> re-read, re-apply, retry
Read
curl -sS -D - -o response.json "$MGMT/issuers/$ISSUER?api-version=2026-08-30" \
-H "Authorization: ApiKey $DILIGENCE_API_KEY"
The ETag header is also in the body as etag.
Update
curl -sS -X PATCH "$MGMT/issuers/$ISSUER?api-version=2026-08-30" \
-H "Authorization: ApiKey $DILIGENCE_API_KEY" \
-H "Content-Type: application/json" \
-H 'If-Match: "AAAAAAAAB9E="' \
-d '{ "displayName": "Workforce Credentials" }'
Handle 412
412 -> re-read the resource
-> re-apply your change to the current state
-> retry with the new ETag
Re-apply, do not replay. If someone else changed the status mechanism while you were changing the display name, replaying your original body would undo their change — which is exactly what the 412 protected you from.
Bound your retries. A resource being updated continuously will keep returning 412, and looping forever is worse than failing.
Omitting If-Match
An unconditional update succeeds. Use that only when you genuinely own the field and nobody else writes it.
In an SDK
The generated clients surface a 412 as a thrown error rather than a null result, so a rejected conditional write cannot be mistaken for a successful one.
try
{
await management.Management.Issuers[issuerId].PatchAsync(
update,
c => { c.QueryParameters.ApiVersion = "2026-08-30"; c.Headers.Add("If-Match", current.Etag!); });
}
catch (ErrorEnvelope error) when (error.Error?.Code == "precondition_failed")
{
// Re-read, re-apply, retry.
}