[Service Bus] Clarify application_properties returns bytes keys/values on receive#48078
Draft
EldertGrootenboer wants to merge 2 commits into
Draft
Conversation
…zure#45082) - Correct the ServiceBusMessage constructor :paramtype for application_properties from Dict[str, ...] to Dict[Union[str, bytes], ...] to match the existing parameter annotation - Add a note on the application_properties property that, when a message is received, keys and string values are returned as bytes, with the bytes-key access and decode pattern; note the same applies to the raw AMQP annotations and delivery_annotations accessed via raw_amqp_message - Add a README sample for reading application properties from received messages - Add a CHANGELOG Other Changes entry Documentation-only change; no behavioral change.
|
Azure Pipelines: Successfully started running 1 pipeline(s). 9 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
There was a problem hiding this comment.
Pull request overview
Clarifies received Service Bus application-property byte behavior across public documentation.
Changes:
- Corrects constructor and property documentation.
- Adds a README usage example.
- Records the clarification in the changelog.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
README.md |
Documents bytes-key access and decoding. |
CHANGELOG.md |
Records the documentation update. |
_common/message.py |
Updates application-property docstrings and types. |
…5082) - Guard the Optional application_properties against None before calling .get in both the docstring and README examples, so copying the sample does not raise AttributeError on a message that carries no application properties - Correct the value-type note: an AMQP timestamp decodes to an integer (milliseconds), not a datetime; list only the verified native types (int, bool, float, uuid.UUID) and reframe as an AMQP-decode description
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
Fixes #45082.
Documentation-only change clarifying that when a message is received,
ServiceBusReceivedMessage.application_propertiesreturns bytes keys andbytes string values (for example
{b"order_id": b"12345"}), notstr.String-key access such as
props.get("order_id")returnsNone; callers mustuse bytes keys and decode string values as needed.
This is intentional, long-standing behavior (the SDK's own tests assert bytes
keys), but the docstrings did not document it — the constructor
:paramtypeeven declared
Dict[str, ...], which contradicts both the actualDict[Union[str, bytes], ...]parameter annotation and the receive behavior.Changes
ServiceBusMessageconstructor docstring — corrected:paramtype application_properties:fromDict[str, ...]toDict[Union[str, bytes], ...](matching the existing parameter annotation)and added a note about the received bytes behavior.
application_propertiesproperty — added a.. note::explaining that,when a message is received, keys and string values are returned as
bytes,with the recommended bytes-key access + decode pattern. Notes that the same
applies to the raw AMQP
annotations/delivery_annotationsaccessed viaraw_amqp_message. Non-string values (int,bool,float,uuid.UUID,datetime) are returned as their native types.received message.
No behavioral/code change — the receive behavior is unchanged; only the
documentation.
Not in scope
Normalizing received keys/values to native strings (to match the .NET, Java, JS,
and Go SDKs) would be a breaking change on this GA package — it would break
every consumer relying on bytes keys today, including the SDK's own tests. That
is a separate design decision, not part of this documentation clarification.