We had some sort of bug that queued up the same message thousands of times, each of them is undelivered because of the spam carrier restrictions, because it was a not real number or something.
We've looked around their docs and stack overflow but can't find anything that looks relevant.
It seems like Twilio keeps trying though - over and over - so it's send out thousands of the same message and keeps queueing them. Or at the very least
How can we clear our whole SMS message queue? We're happy if we never send it again, as nothing in there is mission critical.
The best approach is a ticket to Twilio support via the Twilio Console or help#twilio.com as a P1 (with you Account SID), indicating you have an out of control process queuing up thousands of SMS messages.
They will ask that you fix the process and fail the messages in queue.
Related
I'm testing some flows that use outbound SMS via Twilio and have been really pleased and impressed by the magic numbers provided e.g. https://www.twilio.com/docs/iam/test-credentials
However, I'm interested to see how our application responds if there's some issue sending an SMS to a number where it essentially hits a timeout value. I haven't found a magic number such as this or know of a way to recreate the scenario, can anyone help me here?
Even if you were using a real auth credentials and real phone number (instead of magic number), I suspect Twilio just queues the request on their side and responds with a HTTP 201, so you'll always get a very fast response from Twilio, but it doesn't necessarily mean the message has been sent to a carrier and delivered to a device.
If you're using Twilio messaging services, you can subscribe to delivery status callbacks to get the status of a SMS e.g. sending, sent, delivered, failed, etc - see here. Note: I don't know if you'd receive callbacks with magic numbers - I suspect not... either way you can provision a Twilio phone number pretty cheaply to test e.g. in Australia (where I'm from) I can purchase a AU phone number for $6 per month and I can release the phone number when ever I want to stop getting billed for it...
If you just want your app to timeout on invocation of the Twilio API you can do something like the following (in .NET core) to force timeout a request in a specified amount of time (1 second in example below):
using var tokenSource = new CancellationTokenSource(TimeSpan.FromMilliseconds(1000));
response = await twilioHttpClient.PostAsJsonAsync($"2010-04-01/Accounts/{accountSID}/Messages.json", request, jsonSerializerOptions, tokenSource.Token);
If timeout is exceeded, an exception will be thrown that you can handle. Note: there's various networking tools that can be used to block or limit outbound requests, which you can use to test timeout scenarios.
I am getting the error below when I send bulk messages using Twilio Message Service.
[HTTP 429] Unable to create record: Too Many Requests
I have around 50 numbers in the sender pool in this Message Service.
And I am trying to send about 5K messages at once, some delays are Okay,
But the messages couldn't be sent due to this error,
Thanks in advance,
Twilio developer evangelist here.
A 429 error means that you are exceeding the number of concurrent connections to the Twilio API. By default, this is 100, though it can vary depending on your account.
To counteract this, you should aim to make less than 100 concurrent requests to the API and implement retries with an exponential back off to allow for your other requests to finish.
There is more information on the 429 error here including further links for implementing the above strategies.
There is a number that has been automatically replying with SMS, and of course each reply costs money. It was not a number that was ever sent a message to, so it is baffling as why it is sending automatic responses back.
How does one block a number so not to receive messages from?
Update : Made it clear that reply was in SMS format.
I can't comment yet but please see this
Unlike voice, there’s no way to block specific SMS messages or sending
parties
I am trying to understand before twilio generated error #30003, how many times it tried reaching the end cellphone #, if the subscriber's cell phone is out of range, not available? switched off, temporary disconnected and so on?
Twilio developer here.
Twilio only spends a few seconds trying to deliver an SMS message before determining that the message delivery failed. The exact amount of time varies based on which carrier is used for the delivery.
So if your first attempt to deliver a message failed but you want to try again later, you should add some logic to your application that resends the message to Twilio at a time that makes sense.
Note that Twilio does not charge you for failed attempts to send a message.
Let me know if that helps!
I am doing Comet chat with Erlang. I only use one connection (long-polling) for the message transportation. But, as you know, the long-polling connection can not be stay connected all the time. Every time a new message comes or reaches the timeout, it will break and then connect to the server again. If a message is sent before the connection re-connected, it is a problem to keep the integrity of chat.
And also, if a user opens more than one window with Comet-chat, all the chat messages have to keep sync, which means a user can have lots of long-polling connections. So it is hard to keep every message delivered on time.
Should I build a message queue for every connection? Or what else better way to solve this?
For me seems simplest way to have one process/message queue per user connected to chat (even have more than one chat window). Than keep track of timestamp of last message in chat window application and when reconnect ask for messages after this timestamp. Message queue process should keeps messages only for reasonable time span. In this scenario reconnecting is all up to client. In another scenario you can send some sort of hart beats from server but it seems less reliable for me. It is not solving issue with other reason of disconnection than timeout. There are many variant of server side queuing as one queue per client, per user, per chat room, per ...