[13.x] Wrap retrying job exceptions in JobRetryingException #59271
[13.x] Wrap retrying job exceptions in JobRetryingException #59271jackbayliss wants to merge 1 commit intolaravel:13.xfrom
Conversation
|
Thanks for submitting a PR! Note that draft PRs are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface. Pull requests that are abandoned in draft may be closed due to inactivity. |
|
Hmm, interesting 🤔 so you try to re-queue the job before you see it show up definitively in the failed jobs table? |
|
@taylorotwell I get an alert for any exceptions, so cause this is via a job I assume I need to retry the job, (as it's not clear if it's actually failed or retried right) so I check the DB, to then realise it was already retried automatically, so this just makes it obvious I don't need to do anything 😆 and to anyone else getting the alerts. TLDR is basically its not clear if I/we need to act or not just from the exception so this makes it clear. some jobs are high priority etc, so should be retried ASAP basically. It's also useful for logging tools so we can figure out the flow easily |
2 participants
I regularly see exceptions and think a job has failed, and go to put the job back onto the queue, to realise its not actually failed hard, its just been retried and is already sorted
This PR wraps exceptions in a JobRetryingException when a job is released back to the queue for retry, allowing exception handlers and us to tell the difference between exceptions that caused failure vs. ones where the job will be retried.
Open to renaming it or something different I'm just one man, but trying to make it more obvious as it's hard to tell if it's something we need to act or or not atm.
This is very helpful with tracking tools, Sentry, Mezmo etc.
This is the current trace I get where I need to decide if its a real failure that I may need to manually pop back onto the queue or not :
Details