You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When /auth/mobile/ is invoked, there are two types of failure cases:
SMS sending fails because the user has entered an invalid or non-supported phone number (e.g. country codes that are not enabled by Twilio)
SMS sending fails because Twilio is not configured correctly (e.g. the account has become inactive due to insufficient funds)
In the second case it is crucial that the server admins are notified of this error, whereas in the first case not so much. Right now the only way to achieve this is to try to pattern-match the debug-level log errors sent out by lines such as this, which is very brittle.
Proposed solution(s):
Make the error-catching in send_sms_with_callback_token more robust. Then when an exception is encountered that indicates a server-side fault do one of the following:
a) Throw a 500 error in all cases where it is the fault of the server that the SMS is not being sent.
b) Allow the user to set the logging level of server-side faults in settings.py
c) Optionally invoke a callback of some kind specified in settings.py
I'd be happy with any of these solutions. I think a) is the most elegant, but is not necessarily backwards-compatible, and may tie this package to specific versions of the Twilio API. b) has the drawback that the actual exception itself is not passed to the application level, and that further recovery action would have to be triggered through the logging system. Because a) and b) both have drawbacks I was thinking of submitting a PR with c), but wanted to check here first.
Please let me know the way of solving this that would be best, and I will submit a PR, although I do not use the email functionality and may need guidance on which email-related exceptions to look out for.
The text was updated successfully, but these errors were encountered:
When /auth/mobile/ is invoked, there are two types of failure cases:
In the second case it is crucial that the server admins are notified of this error, whereas in the first case not so much. Right now the only way to achieve this is to try to pattern-match the debug-level log errors sent out by lines such as this, which is very brittle.
Proposed solution(s):
Make the error-catching in
send_sms_with_callback_token
more robust. Then when an exception is encountered that indicates a server-side fault do one of the following:a) Throw a 500 error in all cases where it is the fault of the server that the SMS is not being sent.
b) Allow the user to set the logging level of server-side faults in settings.py
c) Optionally invoke a callback of some kind specified in settings.py
I'd be happy with any of these solutions. I think a) is the most elegant, but is not necessarily backwards-compatible, and may tie this package to specific versions of the Twilio API. b) has the drawback that the actual exception itself is not passed to the application level, and that further recovery action would have to be triggered through the logging system. Because a) and b) both have drawbacks I was thinking of submitting a PR with c), but wanted to check here first.
Please let me know the way of solving this that would be best, and I will submit a PR, although I do not use the email functionality and may need guidance on which email-related exceptions to look out for.
The text was updated successfully, but these errors were encountered: