azure-sdk-for-python
azure-sdk-for-python copied to clipboard
Azure
azure.communication.email.EmailClient send method not throwing error if response status code is 429
- Package Name: azure-communication-email
- Package Version: 1.0.0b1
- Operating System: Linux
- Python Version: 3.8
Describe the bug
When calling send method of EmailClient and rate limiting (Response status 429) has been reached, script hangs and doesn't throw an error.
To Reproduce Steps to reproduce the behavior:
- Create a little script to call the
sendmethod. e.g.
from azure.communication.email import EmailClient, EmailContent, EmailAddress, EmailMessage, EmailRecipients
connection_string = "..."
client = EmailClient.from_connection_string(connection_string);
content = EmailContent(
subject="This is the subject",
plain_text="This is the body",
html= "<html><h1>This is the body</h1></html>",
)
address = EmailAddress(email="...")
message = EmailMessage(
sender="...",
content=content,
recipients=EmailRecipients(to=[address])
)
response = client.send(message)
- Repeat it more than 25 times in a hour (Communication service rate limit)
- Execute it a 26th time
- ... Process hangs
Expected behavior Throw exception so can be caught and processed accordingly
Screenshots Below an example of a Azure Function that receives a 429 immediately, but times out after 5 minutes because no exception has been raised.
Additional context
In our specific case this function is triggered by a Servicebus message. If I had the possibility to catch the exception and the Retry-After value I could potentially re-schedule the message. I have noticed that the library offers a cls parameter that could be used to pass also the Retry-After and not only x-ms-request-id.
Thank you for your feedback. This has been routed to the support team for assistance.
After a bit of debugging we've found a solution to our problem, using a no retry policy.
e.g.
from azure.core.pipeline.policies import RetryPolicy
connection_string = "..."
client = EmailClient.from_connection_string(
connection_string, retry_policy=RetryPolicy.no_retries()
)
This because the email client uses PipelineClient and arguments trickle down to that class and it accept a policy with no retries.
Maybe this could be pointed out in the readme of the lib?
Thanks for looking into this.
G.
Hi @gvnn. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.
@xiangyan99 - I'm not sure this should be marked as addressed. We should not have to resort to changing the retry policy for the correct behaviour - I think the service team needs to address this.
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @acsdevx-msft.
Issue Details
- Package Name: azure-communication-email
- Package Version: 1.0.0b1
- Operating System: Linux
- Python Version: 3.8
Describe the bug
When calling send method of EmailClient and rate limiting (Response status 429) has been reached, script hangs and doesn't throw an error.
To Reproduce Steps to reproduce the behavior:
- Create a little script to call the
sendmethod. e.g.
from azure.communication.email import EmailClient, EmailContent, EmailAddress, EmailMessage, EmailRecipients
connection_string = "..."
client = EmailClient.from_connection_string(connection_string);
content = EmailContent(
subject="This is the subject",
plain_text="This is the body",
html= "<html><h1>This is the body</h1></html>",
)
address = EmailAddress(email="...")
message = EmailMessage(
sender="...",
content=content,
recipients=EmailRecipients(to=[address])
)
response = client.send(message)
- Repeat it more than 25 times in a hour (Communication service rate limit)
- Execute it a 26th time
- ... Process hangs
Expected behavior Throw exception so can be caught and processed accordingly
Screenshots Below an example of a Azure Function that receives a 429 immediately, but times out after 5 minutes because no exception has been raised.
Additional context
In our specific case this function is triggered by a Servicebus message. If I had the possibility to catch the exception and the Retry-After value I could potentially re-schedule the message. I have noticed that the library offers a cls parameter that could be used to pass also the Retry-After and not only x-ms-request-id.
| Author: | gvnn |
|---|---|
| Assignees: | - |
| Labels: |
|
| Milestone: | - |
Adding Service team to look into this.
@acsdevx-msft Could you please look into this once you get a chance ?
