-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] BlobContainerClient should validate the Uri include a container name #43509
Comments
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage. |
Hi @wghilliard: Thanks for reaching out and we regret that you're experiencing difficulties. The Event Hubs library does not directly interact with storage; it makes use of the Azure Storage library for all storage operations, using the I don't believe this is related to token credential use, as this scenario has a comprehensive suite of tests that cover it and run nightly. I see no failures, I am not able to reproduce locally, and we have no other reports of this failure when using credentials. More likely, I suspect that the failure that you're seeing may have something to do with the Please provide a code snippet that demonstrates how you're constructing your |
Hi @wghilliard. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue. |
I think the error could be in how the path is being constructed when performing the partition ownership check, note the trailing slash in the query
Here is the snippet demonstrating how I'm constructing the new BlobContainerClient(new Uri("https://nyancat.blob.core.windows.net/"), tokenCredential); |
It seems like perhaps the exception might be caused by not providing a suffixed container name in the URI. After appending it, I think the SDK is working as expected (currently attempting to get role assignments sorted out such that I can test). Given this was perhaps caused by user error, could we add validation to the BlobContainerClient constructor to ensure the URI is the shape it is expecting? |
@wghilliard: Yes, that's what it appears to be. You're creating a var containerClient = new BlobContainerClient(new Uri("https://nyancat.blob.core.windows.net/mycontainer"), tokenCredential); or use a var containerClient = new BlobServiceClient(new Uri("https://nyancat.blob.core.windows.net"), tokenCredential)
.GetBlobContainerClient("mycontainer");
I agree that would be a good idea. I'll update the title and leave this open for the Azure Storage team to review/consider, as the owners of the Storage SDK packages. //cc: @amnguye |
I could see the SDK providing a way to validate blob container Uri's, to validate the name is in the URL. This does require us to make sure we cover all our bases with every single type of storage Uri out there (e.g. host IP style endpoints). Today we don't have checks on the Uri passed to any storage client constructor. I believe adding these checks wouldn't break any happy path behavior (since people would know they passed an invalid Uri eventually, when they go to make an API call). I wonder though if it does break those who are mocking the storage clients (e.g. @seanmcc-msft @jaschrep-msft Are we good to just throw an |
That's a good point about mocks, perhaps the builder or an option during construction to run / suppress validation?? |
This comment was marked as spam.
This comment was marked as spam.
Reading through the comments here, it seems like we can leverage BlobUriBuilder to validate if the BlobContainerName is set in the Uri passed into BlobContainerClient's ctor. If not we can throw an argument exception. This seems like relatively straightforward fix and would be useful, though the existing mocks could be an issue. Bumping @amnguye question from above, what are yalls thoughts on this fix? @seanmcc-msft @jaschrep-msft |
Azure Storage Team: Please see the last two comments in the discussion thread for the feature request and rationale behind it.
Library name and version
Azure.Messaging.EventHubs 5.11.2
Describe the bug
When using a
BlobContainerClient
with aTokenCredential
for checkpointing with theEventProccessorClient
, the processor fails on startup because of a malformed query being sent via theBlobContainerClient
. This issue is not reproducible when using a Connection String for theBlobContainerClient
.Expected behavior
The EventProcessorClient should successfully check the ownership of the of the partition using the BlobContainerClient, however it seems like it's adding an extra slash to the query which is causing a 400.
Actual behavior
The EventProcessorClient fails to start because ownership of the partition cannot be read.
Reproduction Steps
BlobContainerClient
with aTokenCredential
.EventProcesserClient
with the previously createdBlobContainerClient
.Below is the error message I encountered.
Environment
The text was updated successfully, but these errors were encountered: