Is it “safe” to update the args for an Oban job that is currently scheduled to run? Or is there a potential race condition where the job may start running with the old args before the args are updated in the DB?
1 Like
A job that is in the scheduled state must transition to the available state before it executes; it will never jump straight from scheduled to executing. Using FOR UPDATE in a transaction to do the update will help prevent a potential race condition as it’s a soft lock.
The preferred way to accomplish this is with unique and the replace option:
unique: [period: :infinity, states: [:scheduled], keys: [:id]],
replace: [scheduled: [:args]]
Then, when you go to insert the job and there’s an existing job with a unique conflict it will selectively update the args. Note that it’s only looking at a distinct field, like id, because comparing the full args map would never match 
This is especially effective with Pro’s enhanced unique mechanism, since it is index backed.
2 Likes
Great, thank you for info!
