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
This is something that's ultimately my fault, but I thought solid_queue could ultimately have some more defensive behavior. Here is an outline of the issue:
During refactoring, I removed a Job class that was no longer needed
After launching these changes, things worked as normal until a scheduled job of the removed class was due for execution.
Upon scheduled execution, solid_queue tried to gain the concurrency lock, but the job class was nil when delegated to
The nil job class caused the process to crash, causing the supervisor to fork the process and try again. This repeated continuously
None of the other scheduled jobs were able to process, because the initial (nil class) job was blocking the queue from continuing.
This should have been handled (and ultimately was) via removing the scheduled jobs for the removed class, but it seems there is room for some more defensive behavior, allowing the queue to continue processing and creating some kind of failed execution record.
Here is a screenshot of some of the backtrace during this issue:
Thanks for considering and please let me know if you'd like any further info!
The text was updated successfully, but these errors were encountered:
Hi there,
This is something that's ultimately my fault, but I thought solid_queue could ultimately have some more defensive behavior. Here is an outline of the issue:
Here is a screenshot of some of the backtrace during this issue:
Thanks for considering and please let me know if you'd like any further info!
The text was updated successfully, but these errors were encountered: