Download Latest Version v2.22.1 source code.tar.gz (331.8 kB)
Email in envelope

Get an email when there's a new version of Oban

Home / v2.20.2
Name Modified Size InfoDownloads / Week
Parent folder
README.md 2025-12-04 2.0 kB
v2.20.2 source code.tar.gz 2025-12-04 323.1 kB
v2.20.2 source code.zip 2025-12-04 400.9 kB
Totals: 3 Items   726.0 kB 0

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.

Source: README.md, updated 2025-12-04