NotificationFailed flow not ideal
aphofstede opened this issue · comments
When a queued SMS notification fails to send, a NotificationFailed event is fired. Currently, the NotificationSent event is still fired and all looks green in Telescope. Could the TwilioChannel be made a bit more verbose and mark the queued job as failed?
Aside: Would be nice if the documentation would cover catching NotificationFailed events.
The issue seems to be that the exceptions are caught, handled, and suppressed.
Wouldn't it make more sense to catch the Exception, fire the NotificationFailed event, and then continue to throw the Exception? This would show the job as being failed.
Simple re-throwing of the exceptions may break existing applications.
For example: Twilio client throws an exception in case of invalid receiver phone number or in case receiver phone number belongs to unsupported region.
See:
- https://www.twilio.com/docs/api/errors/21608
- https://www.twilio.com/docs/api/errors/21211
- https://www.twilio.com/docs/api/errors/21614
- https://www.twilio.com/docs/api/errors/21408
If this PR accepted Laravel application may easily end up in 500 error in case user entered incorrect phone number by a mistake.
I suggest there should be a configuration parameter, which should hold the list of error codes, which appearance will be considered as a valid outcome. For example:
<?php
return [
'twilio' => [
// ...
'ignored_error_codes' => [
21608,
21211,
21614,
21408,
],
],
];As for NotificationFailed event - we can add some flag into it, which will indicate whether this event has or has not been handled.
If flag is false after event dispatched - we can re-throw and exception.
Still, such solution may produce incorrect results in case event listener is defined to be asynchronous with the queue.
ping @atymic yea i also faced it. And the issue was catching every exception inside send method? Isn't it better to throw error so we can see error on queues etc?
ping @atymic yea i also faced it. And the issue was catching every exception inside send method? Isn't it better to throw error so we can see error on queues etc?
The problem with this is that the Twilio library sometimes throws an exception with an error code even though the notification has been sent. An exception does not imply that the message was not sent.
Simple re-throwing of the exceptions may break existing applications.
For example: Twilio client throws an exception in case of invalid receiver phone number or in case receiver phone number belongs to unsupported region.
See:
- https://www.twilio.com/docs/api/errors/21608
- https://www.twilio.com/docs/api/errors/21211
- https://www.twilio.com/docs/api/errors/21614
- https://www.twilio.com/docs/api/errors/21408
If this PR accepted Laravel application may easily end up in 500 error in case user entered incorrect phone number by a mistake.
To avoid breaking current integrations. Maybe we can introduce the changes to a major release of this library.
I've created a PR for v3 (major version bump) with configurable error handling. Please check out the PR here: #90