When not using Oban Pro, how would one release a job that’s been suspended into the available state? Oban.update_job/3 won’t validate the state key in the changes map and there’s no separate function to move a job into that state (unlike Oban.retry_job/2). The only solution I’ve found so far is using Oban.retry_job/2 which would eventually make it available.
The short version is that you wouldn’t. Oban never inserts suspended jobs, only Pro does.
You’re not meant to change job states manually with update_job or through the database. Use the functions provided by Oban for cancelling, retrying, etc. because they ensure the correct timestamps are set and respect constraints.
The retry_job function is oddly named because a job doesn’t need to have failed to use it. It is the correct way to make a job available to run.
1 Like
It’s not documented, but the changeset cast in Oban.Job.new accepts state as a permitted parameter, so I was starting a job as suspended with %{} |> __MODULE__.new(state: "suspended") |> Oban.insert() (which would then later be retried by another process). Should I not be creating suspended jobs then?
That’s used for testing, you’re not intended to insert jobs in arbitrary states. Inserting normally goes to available, and inserting with a schedule* option results in scheduled.
Nope, sorry. It’s meant for use in Pro. Here’s a note about it in the CHANGELOG:
While Oban itself doesn’t make use of suspended jobs, the state enables Pro workflows to defer execution without any workarounds or performance impact.
For normal operation, there’s no advantage over simply scheduling far in the future.
