Repository navigation
[429 The rate limit has been reached] Bandwidth Messaging crashes with unhandledpromiserejection #58
Description
### Checklist
- Have you provided a description of the bug?
- Have you provided your Environment information?
- Have you provided a sample code snippet?
- Have you provided a stack trace?
- Have you outlined the expected behavior?
Description
We send out messages to 100s of users 1 by 1. The problem is that since last month we are seeing a lot of "429 The rate limit has exceeded warnings and it crashes our backend even though we are using try catch.
Environment Information
- OS Version: (Linux)
- SDK Version: (e.g. 4.0.1)
- Environment: (e.g. Node 16)
Sample Code Snippet
for (const phoneNumber of uniqueToPhoneNumbersArray) {
try {
const body: MessageRequest = {
applicationId,
to: [phoneNumber],
from: fromPhoneNumber,
text: messageString ,
priority: priority || PriorityEnum.Default
}
controller.createMessage(accountId, body)
} catch (error) {
return {
success: false,
errors: [error]
}
}
}Stack Trace
/var/www/firetext-web/node_modules/@bandwidth/messaging/dist/messaging.cjs.production.min.js in at line 1:8445
1
System
'{snip} r"!=typeof t&&r.statusCode>=t[0]&&r.statusCode<=t[1])throw new e(n,...o);return n})}async call(t){const e=function(t,e){let o=e;for(let e=t. {snip}
//# sourceMappingURL=messaging.cjs.production.min.js.map
/var/www/firetext-web/node_modules/@bandwidth/messaging/dist/messaging.cjs.production.min.js in runMicrotasks
System
internal/process/task_queues.js in processTicksAndRejections at line 95:5
System
/var/www/firetext-web/node_modules/@bandwidth/messaging/dist/messaging.cjs.production.min.js in at line 1:8172
5
System
'{snip} e),o))}interceptResponse(t){this.intercept(async(e,o,n)=>t(await n(e,o)))}defaultToError(t){this._apiErrorFactory=t}validateResponse(t){this {snip}
//# sourceMappingURL=messaging.cjs.production.min.js.map
/var/www/firetext-web/node_modules/@bandwidth/messaging/dist/messaging.cjs.production.min.js in $.call at line 1:8696
System
'{snip} onse:await this._httpClient(t,e)})),{request:o,response:n}=await e(this.toRequest(),t);return{...n,request:o,result:void 0}}async callAsText {snip}
//# sourceMappingURL=messaging.cjs.production.min.js.map
/var/www/firetext-web/node_modules/@bandwidth/messaging/dist/messaging.cjs.production.min.js in $.callAsJson at line 1:9314
System
'{snip} (e,"accept","application/json"),{...t,headers:e}});const o=await this.call(e);if(""===o.body)throw new Error("Could not parse body as JSON. {snip}
//# sourceMappingURL=messaging.cjs.production.min.js.map
### Expected Behavior
it was working fine like a month ago. expected to work normally without crashing.
### Suggested Fix
Activity
[-][429 The rate limit has been reached] [/-][+][429 The rate limit has been reached] Bandwidth Messaging crashes with unhandledpromiserejection[/+]firetextsaad commentedon May 23, 2023
@hamermike
kindly take a look
ckoegel commentedon May 25, 2023
Hey @firetextsaad
I've been investigating this and I haven't been able to completely reproduce. When receiving a 429, the SDK is able to catch it immediately and throws a
MessagingExceptionError, the only way I could reproduce theCould not parse body as JSON.error was to force a 2XX with no response body.This aside, the snippet you posted seems to highlight an issue, since the
controller.createMessage(accountId, body)(which is async) is notawaited inside the try catch, the promise is not resolved inside the try catch, and the error surfaces outside of the try catch block once the promise is resolved. I was able to fix this by making that lineawait controller.createMessage(accountId, body)instead.If this doesn't solve your issue, please let me know what version of the SDK you're using and maybe a larger snippet + some more logs and I'll investigate further.
firetextsaad commentedon May 26, 2023
@ckoegel first of all thank you so much for your contribution
indeed very good catch without await trycatch has no use here.
thanks man, it will really save a lot of head scratching.
the goal was to send out messages to 100s of users instantly so i did not use await.
which is now proved to be the wrong approach.
to tackle that, i am now going to use await like
controller.createMessage(accountId, body)and then call that function in bursts. this solves the issue about not being able to catch that error.but 429 will still occur right ?
if it still happens, i will share the stack trace and any findings with you after modifying the code to properly catch it
ckoegel commentedon May 30, 2023
No problem, glad I could help!
There is still a chance you will hit a rate limit, but that'll depend on the rate limit for your account or the individual number. You should be able to implement some retry logic by catching the 429 and waiting a little bit; how long to wait would also depend on your rate limit and queue size. We have an article explaining some of it here
firetextsaad commentedon Jun 7, 2023
thanks for providing the additional information on the topic.
we need to send out messages as early as possible as these are critical messages. if it is not delivered we do not resent it.
i think the only option we have is to increase the rate limit for now.