build(deps): Bump oban from 2.18.0 to 2.20.2

[dependabot]

Bumps oban from 2.18.0 to 2.20.2.

Release notes

Sourced from oban's releases.

v2.20.0

This release brings a fantastic new helper function, an optional migration to aid pruning, some stability improvements, and a bevy of documentation updates.

🦋 Update Job

This introduces the Oban.update_job/2,3 function to simplify updating existing jobs while ensuring data consistency and safety. Previously, updating jobs required manually constructing change operations or complex queries that could lead to race conditions or invalid state changes.

Only a curated subset of job fields, e.g. :args, :max_attempts, :meta, etc. may be updated and they use the same validation rules as insertion to prevent invalid data. Updates are also wrapped in a transaction with locking clauses to prevent concurrent modifications.

The function supports direct map changes:

Oban.update_job(job, %{priority: 0, tags: ["urgent"]})

It also has a convenient function-based mode for dynamic changes:

Oban.update_job(job, fn job -> 
  %{meta: Map.put(job.meta, "processed_by", current_node())} 
end)

❄️ Unique State Groups

There are now named unique state groups to replace custom state lists for unique jobs, promoting better uniqueness design and reducing configuration errors.

Previously, developers had to manually specify lists of job states for uniqueness, which was error-prone and could lead to subtle bugs when states were omitted or incorrectly combined. The new predefined groups ensure correctness and consistency across applications.

The new state groups are:

• :all - All job states
• :incomplete - Jobs that haven't finished (~w(available scheduled executing retryable)a)
• :scheduled - Only scheduled jobs ([:scheduled])
• :successful - Jobs that completed successfully (~w(available scheduled executing retryable completed)a)

These groups eliminate the risk of accidentally creating incomplete or incorrect state lists that could allow duplicate jobs to be created when they shouldn't be, or prevent valid job creation when duplicates should be allowed.

🪺 Nested Plugin Supervision

Plugins and the internal Stager are now nested within a secondary supervision tree to improve system resilience and stability.

Previously, plugins were supervised directly under the main Oban supervisor alongside core process. This meant that plugin failures could potentially impact the entire Oban system, and frequent plugin restarts could trigger cascading failures in the primary supervision tree.

The new supervisor has more lenient restart limits to allow for more plugin restart attempts before giving up. This change makes Oban more robust in production environments where plugins may experience transient failures due to database or connectivity issues.

v2.20.0 — 2025-08-13

Enhancements

... (truncated)

Changelog

Sourced from oban's changelog.

v2.20.2 — 2025-12-04

Enhancements

• [Telemetry] Add domain to attach_default_logger metadata

  Although this information is present in the source attribute, it’s not part of the metadata, it’s part of the attributes. And when encode = true, it’s generated as a string, which makes it less convenient to work with.

• [Cron] Add unique cron entry identifiers to job meta

  A id value is generated for each cron entry and stored in the job's meta to distinguish between different cron jobs with the same expression.

Bug Fixes

• [Stager] Order staging query to maximize compound index usage

  The core compound index couldn't be utilized by staging queries when the planner estimated a large number of hits. Changing the query to order by scheduled_at and id, it becomes an index scan.

  It would still be more efficient to use a dedicated index, but OSS doesn't have any mechanisms for automatic concurrent index creation and we have to save it for later.

• [Executor] Take measurements from the executing process

  When Producer starts jobs, it calls Executor.new in its own process, before handing it off to Task.Supervisor.async_nolink to call Executor.call. That means it used the Producer pid, and took measurements from that process.

• [Oban] Set scheduled state correctly when updating with update_job/3

  When the scheduled_at timestamp is set during update_job, the state is automatically set to scheduled. This mirrors the functionality of insert_job.

  Note that the value of the timestamp isn't considered. Setting a timestamp in the past will set the job as scheduled. This isn't a problem in practice because the stager will change the state to available on the next cycle anyhow.

• [Repo] Include :deadlock_detected in expected errors

  Deadlocks are automatically resolved by Postgres because it aborts one transaction. At that point, the retry should succeed quickly since the blocking transaction is gone.

v2.20.1 — 2025-08-15

Bug Fixes

... (truncated)

Commits

• 6e57e4b Release v2.20.2
• e13b071 Include :deadlock_detected in expected errors
• 3f67421 Bump credo from 1.7.13 to 1.7.14 in the development-dependencies group (#1376)
• 854b7fd Bump actions/checkout from 5 to 6 (#1375)
• 1d2c1f8 Update development dependencies
• 106f3ea Bump the production-dependencies group with 2 updates (#1369)
• d1789f1 README.md: Update explanatory link for queues (#1368)
• a92ca5e Add domain to log metadata (#1364)
• aa24e3b Update matrix for Elixir v1.19 and OTP 28.1
• a1d20f2 Order stage query to maximize compound index usage
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)