Open McSneaky opened 1 year ago
Interesting concept, I remember reading about something similar in another package (I wish I could remember it to share) but their strategy was not to drop the new one, but pull the old one out and queue up the new one. Maybe the new one has newer info and makes more sense to keep that one over the old one.
Sometimes it's good to limit how many of certain type of jobs can be queued
For example when there's job to send "Reset password email", when client clicks on "Reset PW" button. Problem is, if client starts smashing that button for tens of times before job has been ran (maybe bad example)
As one potential way to solve it would add
key
to each job and user can set thatkey
Then when job is saved and it's it's set to be unique, we can compare
key
to already queued up jobs. If one job is already queued, then queueing new one will be dropped (or maybe it should throw error: "Job already queued"? 🤔 )