-
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
[Messaging] Allow binary application properties #43181
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The focus of these changes is to update AMQP conversion to remove the validation that disallows `byte[]` and `ArraySegment<byte>` values in application properties. These are confirmed to be encoded as `binary` by `Microsoft.Azure.Amqp`, making them allowable values according to section 3.2.5 of the AMQP specification. The Event Hubs documentation for `EventData` has been updated to reflect this change. Due to a known bug in the Service Bus service, the service will reject messages with `byte[]` application properties. Until this is confirmed fixed, the Service Bus documentation still reflects `byte[]` as an invalid type for the application properties.
jsquire
added
Event Hubs
Client
This issue points to a problem in the data-plane of the library.
labels
Apr 3, 2024
/azp run net - eventhub - tests |
Azure Pipelines successfully started running 1 pipeline(s). |
christothes
reviewed
Apr 3, 2024
…operties by sequence rather than simple equality.
/azp run net - eventhub - tests |
Azure Pipelines successfully started running 1 pipeline(s). |
and adding docs for the service error related to binary properties with suggested workaround.
m-redding
approved these changes
Apr 4, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks good to me - the tests are very comprehensive 👍
christothes
reviewed
Apr 4, 2024
sdk/eventhub/Azure.Messaging.EventHubs.Shared/src/Testing/EventDataExtensions.cs
Outdated
Show resolved
Hide resolved
JoshLove-msft
approved these changes
Apr 4, 2024
christothes
approved these changes
Apr 4, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
The focus of these changes is to update AMQP conversion to remove the validation that disallows
byte[]
andArraySegment<byte>
values in application properties. These are confirmed to be encoded as binary byMicrosoft.Azure.Amqp
, making them allowable values according to section 3.2.5 of the AMQP specification.The Event Hubs documentation for
EventData
has been updated to reflect this change. Also riding along is a non-trivial clean-up of the Event Hubs-specific AMQP message converter, which had a number of members that were replaced by theAzure.Core.Amqp
converter implementation.Due to a known bug in the Service Bus service, messages with
byte[]
application properties result in an error when being sent from the client. Until this is confirmed fixed, the Service Bus documentation still reflectsbyte[]
as an invalid type for the application properties. While the client will no longer validatebyte[]
, any use will trigger a service error. Regrettably, this does change the error behavior when this specific type is used, but this is both short-term (confirmed that the service bug will be fixed this semester) and it is enough of an edge case that I do not believe taking a performance hit on each serialization to maintain the current behavior is justified. Likewise, I don't believe that this is impactful enough to take on the technical debt required to add a short-term flag to customize serialization behavior.