We throw a 500 error when someone who has already texted "stop" (a Twilio special word, which prevents us from texting them) texts or calls in again.
Specifically, we don't gracefully handle the following error from Twilio:
Twilio::REST::RequestError - The message From/To pair violates a blacklist rule.
and so the web app gives a 500 error response.
This is low-priority, since it really only affects logs, but we would want to gracefully handle this and return a 200 but change no behavior for the user. (Or, if we do want people to be able to get off their self-assigned block we will need a separate flow, but I'd open another issue for this.)
Have seen this sporadically, maybe 2x a month — it raises and returns a 500 error. The solution remains just catching that specific raise and returning a non-error code (though not texting the user.)
We throw a 500 error when someone who has already texted "stop" (a Twilio special word, which prevents us from texting them) texts or calls in again.
Specifically, we don't gracefully handle the following error from Twilio:
Twilio::REST::RequestError - The message From/To pair violates a blacklist rule.
and so the web app gives a 500 error response.
This is low-priority, since it really only affects logs, but we would want to gracefully handle this and return a 200 but change no behavior for the user. (Or, if we do want people to be able to get off their self-assigned block we will need a separate flow, but I'd open another issue for this.)