Skip to content
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

[ServiceBus] Message body allows dictionary but can't receive the message #14500

Closed
divyag9 opened this issue Oct 14, 2020 · 3 comments
Closed
Assignees
Labels
Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. feature-request This issue requires a new behavior in the product in order be resolved. Service Bus

Comments

@divyag9
Copy link

divyag9 commented Oct 14, 2020

  • azure-servicebus:
  • 7.0.0b6:
  • Windows:
  • 3.7.9:

Describe the bug
According to the docs azure.servicebus.Message can accept string or bytes as body but by mistake I sent a dictionary without converting to string or bytes, the message was sent but I was not able to receive message on the other end. I spent a lot of time thinking my code was wrong on the other side cause I see there is a message active in the service bus.
Later I realized the error is because I sent the body without converting to string or bytes. Is there a way we could check for the type when creating the message?

To Reproduce
Following is example code which resulted in message getting stuck in the servicebus.
dict_test = {
"test1": "",
"test2": {
"test3": "",
"test4": "",
"test5":"westus2",
"test6": "2020-09-24"
},
}
message = Message(dict_test)

Expected behavior
Should not allow message body to be other type than string or bytes

@ghost ghost added needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. customer-reported Issues that are reported by GitHub users external to the Azure organization. question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Oct 14, 2020
@ghost ghost removed the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Oct 14, 2020
@KieranBrantnerMagee
Copy link
Member

Hey @divyag9 ;
Thanks for reaching out! This is more perfect timing that you probably know, as we were contemplating this failure mode internally, and you've given strong impetus to taking action on it.

I believe were're in agreement as to the semantic goal, that invalid types should fail-fast with a ValueError during Message construction; the subtlety that we've been debating has been how to do this validation in a robust and complete way, as the breakdown of valid types is a little more fine-grained then mentioned. (e.g. there are some valid AMQP scenarios involving lists, although the behavior is sometimes unintuitive)

Will keep this thread looped in as we settle on a conclusion and PR it in, expect to see something in this release cycle, and don't hesitate to shout here if you have any thoughts on the above or additional color to add.

@KieranBrantnerMagee KieranBrantnerMagee added Client This issue points to a problem in the data-plane of the library. feature-request This issue requires a new behavior in the product in order be resolved. and removed question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Oct 15, 2020
@divyag9
Copy link
Author

divyag9 commented Oct 23, 2020

Great thank you!

@yunhaoling yunhaoling added this to the [2020] December milestone Nov 6, 2020
@yunhaoling yunhaoling added the blocking-release Blocks release label Nov 10, 2020
@KieranBrantnerMagee KieranBrantnerMagee removed the blocking-release Blocks release label Nov 20, 2020
@KieranBrantnerMagee
Copy link
Member

Hey @divyag9 , just wanted to close this out with the good news that the 7.0 GA release contains the expected fail-fast behavior in Message construction.

There is ongoing work in accordance to python guidelines to support Valid dict-representations in leiu of strongly typed arguments (see here ) but this should not distract from the behavior when an invalid dict is passed, to immediately raise a TypeError.

Don't hesitate to shout/reopen if any further questions or issues, and thanks as always for reaching out and your patience as we addressed this!

@github-actions github-actions bot locked and limited conversation to collaborators Apr 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. feature-request This issue requires a new behavior in the product in order be resolved. Service Bus
Projects
None yet
Development

No branches or pull requests

4 participants