search

craigpaul / laravel-postmark

A Postmark adapter for Laravel
MIT License
203 stars 23 forks source link

How to capture exceptions inside postmark api #27

Closed mberneis closed 5 years ago

mberneis commented 5 years ago

I am getting exceptions in my log for certain emails when people try resetting their password.

(see below) - Is there a recommended way of capturing those or avoiding these altogether?

Using latest version 2.4 with laravel 5.8.8

Message
Client error: `POST https://api.postmarkapp.com/email` resulted in a `422 Unprocessable Entity` response:
{"ErrorCode":406,"Message":"You tried to send to a recipient that has been marked as inactive.\nFound inactive addresses (truncated...)
Level
ERROR
Exception
```{
   "class": "GuzzleHttp\\Exception\\ClientException",
   "message": "Client error: `POST https:\/\/api.postmarkapp.com\/email` resulted in a `422 Unprocessable Entity` response:\n{\"ErrorCode\":406,\"Message\":\"You tried to send to a recipient that has been marked as inactive.\\nFound inactive addresses (truncated...)\n",
   "code": 422,
   "file": "\/home\/forge\/www.nanochipid.com\/releases\/20190414015353\/vendor\/guzzlehttp\/guzzle\/src\/Exception\/RequestException.php:113",
   "trace": [
...
craigpaul commented 5 years ago

Hey @mberneis, I have gotten those errors before, but its actually stating that this specific recipient has been marked as inactive. I'm not sure what this package can do (if anything) to assist in this situation, but if you have any suggestions beyond what postmark recommends in the link above, please let me know 👍

Edit: Oh my mistake, you're asking about capturing these exceptions. I'm not sure how these can be caught from within a Laravel application as it should be within the channel (assuming you're using the notification system and not just the mailer). There is an event called NotificationFailed, but I don't know if that event is used by the default email channel for notifications. I personally have made my own email channel that fires that event.

mberneis commented 5 years ago

Thank you for the quick response - Yes, I would prefer just to get a Log::warning instead of the exception. Maybe there could be a configuration setting and the exception can be caught when calling guzzle. Would you think that might be a worthwhile feature? - If so I will start working on a PR

craigpaul commented 5 years ago

I would have no objection to it, as long as its opt-in by default since it deviates from how Laravel's built in transports work 👍