Open joelverhagen opened 1 year ago
@joelverhagen
Thanks for reporting this issue! This should be caused by the Azurite error definition doesn't include client request ID, like getContainerAlreadyExists . To fix this, we need add "x-ms-request-id" into the base class StorageError , and pass the client request ID from request to the constructor function of StorageError.
As we are working on some other features and PR reviews, this might won't be out priority in the recent future. It would be great if you can raise a PR to fix it! (There might will be a lot of code change as there are so many API/error need change.)
any update on this?
@udlose
Azurite welcome contribution! It would be great if you could raise a Pr to fix this.
The general idea to fix this is already shared above. Feel free to raise if you have any detail questions.
Which service(blob, file, queue, table) does this issue concern?
Confirmed on blob and table, likely exists for the other APIs
Which version of the Azurite was used?
3.27.0
Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
VS Code extension
What's the Node.js version?
v18.18.2
What problem was encountered?
Some error responses that come back from Azurite do not echo the
x-ms-client-request-id
request header as a response header. This works for successful requests in all the cases I have tried. This is a different behavior from real Azure Storage. Consider the "create blob container" or "create table" APIs. These return a 409 Conflict when the entities already exist. Azurite does not return thex-ms-client-request-id
response header on 409 but Azure Storage does.Steps to reproduce the issue?
Debug log:
Repro app:
Output from Azure Storage (good):
Output from Azurite (bad -- missing x-ms-client-request-id on some responses)
Have you found a mitigation/solution?