Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
azure.communication.email.EmailClient send method not throwing error if response status code is 429
See original GitHub issue- 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.
Issue Analytics
- State:
- Created a year ago
- Comments:7 (2 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@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.
Adding Service team to look into this.
@acsdevx-msft Could you please look into this once you get a chance ?