Summary
Track an Azurite compatibility gap for conditional stat and read on a missing blob. When If-Match contains a valid ETag obtained from another blob, the live Azure Blob Storage service returns 404 BlobNotFound, while Azurite returns 412 ConditionNotMet.
This is an Azurite parity issue, not an OpenDAL or Azure Blob Storage capability limitation.
Verified behavior
Reproduced with raw Shared Key REST requests using x-ms-version: 2022-11-02. The condition used a valid ETag returned after creating another blob in the same container.
| Backend |
Version |
HEAD missing blob |
GET missing blob |
| Azure Blob Storage |
live service |
404 BlobNotFound |
404 BlobNotFound |
| Azurite |
3.35.0 |
412 ConditionNotMet |
412 ConditionNotMet |
| Azurite |
3.37.0 |
412 ConditionNotMet |
412 ConditionNotMet |
A synthetic malformed ETag is not an equivalent reproduction: Azure Storage may itself return 412 for that input. The parity difference is observable when both requests use an ETag issued by the service.
Upstream report: Azure/Azurite#2751
OpenDAL handling
OpenDAL's portable stat/read contract preserves NotFound when the target does not exist, including when if_match is set. The Azure Blob Storage backend satisfies this contract against the live service and should continue advertising stat_with_if_match and read_with_if_match.
Until Azurite matches Azure Storage, its behavior-test configuration should override only these emulator capabilities:
stat_with_if_match=false,read_with_if_match=false
Do not disable the Azure Blob Storage backend capabilities globally. Do not add a client-side existence probe: it would add another request and introduce a time-of-check/time-of-use race.
Completion criteria
Related to #8168.
AI assisted with the live-service comparison and drafting. The contributor directed the scope and conclusion.
Summary
Track an Azurite compatibility gap for conditional stat and read on a missing blob. When
If-Matchcontains a valid ETag obtained from another blob, the live Azure Blob Storage service returns404 BlobNotFound, while Azurite returns412 ConditionNotMet.This is an Azurite parity issue, not an OpenDAL or Azure Blob Storage capability limitation.
Verified behavior
Reproduced with raw Shared Key REST requests using
x-ms-version: 2022-11-02. The condition used a valid ETag returned after creating another blob in the same container.404 BlobNotFound404 BlobNotFound412 ConditionNotMet412 ConditionNotMet412 ConditionNotMet412 ConditionNotMetA synthetic malformed ETag is not an equivalent reproduction: Azure Storage may itself return
412for that input. The parity difference is observable when both requests use an ETag issued by the service.Upstream report: Azure/Azurite#2751
OpenDAL handling
OpenDAL's portable stat/read contract preserves
NotFoundwhen the target does not exist, including whenif_matchis set. The Azure Blob Storage backend satisfies this contract against the live service and should continue advertisingstat_with_if_matchandread_with_if_match.Until Azurite matches Azure Storage, its behavior-test configuration should override only these emulator capabilities:
Do not disable the Azure Blob Storage backend capabilities globally. Do not add a client-side existence probe: it would add another request and introduce a time-of-check/time-of-use race.
Completion criteria
Related to #8168.
AI assisted with the live-service comparison and drafting. The contributor directed the scope and conclusion.