ConditionNotMet
Azure Storage returns `ConditionNotMet` when conditional headers fail; writes typically return HTTP 412 Precondition Failed.
Last reviewed: February 14, 2026|Editorial standard: source-backed technical guidance
What Does Condition Not Met Mean?
Optimistic concurrency checks rejected the operation, so the write/read flow must reconcile resource state before it can proceed safely.
Common Causes
- -If-Match or If-None-Match header uses stale ETag after another writer updated the object.
- -Lease-dependent operation is sent with missing or mismatched lease ID.
- -Conditional timestamp headers do not match the current blob state.
- -Parallel workers race on the same object without coordinated write ordering.
How to Fix Condition Not Met
- 1Read the latest object properties and refresh ETag/lease values before retrying.
- 2Send conditional headers that match current resource version and operation intent.
- 3Serialize conflicting writes for hot objects or apply optimistic retry with state refresh.
- 4Avoid blind retry loops; re-evaluate state between attempts.
Step-by-Step Diagnosis for Condition Not Met
- 1Capture request headers (
If-*, lease ID), response status, andx-ms-request-id. - 2Compare provided ETag/lease with current server-side values from object properties.
- 3Trace concurrent writers touching the same blob/key in the same time window.
- 4Retest with a read-refresh-write cycle to verify condition handling logic.
Conditional Header and ETag Integrity
- -Audit ETag refresh boundaries in client code (example: worker reuses cached ETag across multiple mutations after another worker updated blob).
- -Inspect conditional header semantics per operation (example:
If-None-Match: *used for overwrite path that should requireIf-Match).
Lease and Writer Concurrency Controls
- -Validate lease lifecycle around mutating operations (example: lease expired between acquire and write, causing 412 failure).
- -Trace concurrent mutation paths and enforce single-writer guards (example: two queue consumers update same manifest blob simultaneously).
How to Verify the Fix
- -Replay the mutation path and confirm conditional operations succeed without 412 failures.
- -Verify concurrency controls preserve intended write ordering under load.
- -Observe reduced
ConditionNotMetrate in storage diagnostics over subsequent deployments.
How to Prevent Recurrence
- -Implement standard read-refresh-write helpers for all conditional storage operations.
- -Use bounded retries that always re-fetch object state before each attempt.
- -Partition or lock high-contention keys to reduce cross-worker write races.
Pro Tip
- -persist last-seen ETag with operation metadata and reject stale worker jobs before they reach the storage write call.
Decision Support
Compare Guide
403 Forbidden vs 404 Not Found: When to Hide Resources
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Compare Guide
404 Not Found vs 410 Gone: Missing vs Permanent Removal
Learn when to return 404 (missing or temporary absence) versus 410 (intentional permanent removal), including redirect and cache implications.
Playbook
Conflict and Concurrency Playbook (409 / 412 / OptimisticLock)
Use this playbook to separate true write conflicts from stale precondition failures, then apply safe re-fetch, optimistic-lock, and retry choices.
Playbook
Resource State Playbook (404 / 410 / ResourceNotFound)
Use this playbook to separate temporary missing-resource lookups from permanent removals, then fix scope, lifecycle, and identifier drift safely.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.