Oban Pro compatibility

Copy Markdown View Source

Status: likely compatible, unverified, untested. queue_keeper_check has never been run against Oban Pro. Pro is distributed from a private package repository that requires a paid license, which this project does not have, so there are no Pro tests in CI and none of the statements below were checked against a running Pro system. Everything here comes from reading Pro's public documentation (Pro v1.8.3 docs, read on 2026-10-22). Treat it as a list of things to verify in your own pilot (see "Piloting safely" in the README), not as a guarantee.

Some checks could produce false results under Pro. The cases we know of are listed below.

Why it should mostly work

  • Oban.Pro.Engine (called Oban.Pro.Engines.Smart before Pro v1.8; the old name still works) is an Oban.Engine that "is responsible for all non-plugin database interaction, from inserting through executing jobs". Jobs live in the same oban_jobs table, with the same columns and states that queue_keeper_check reads (state, queue, worker, attempt, scheduled_at, attempted_at, discarded_at, cancelled_at, inserted_at). Pro adds its own tables (oban_producers, and in v1.8 oban_pruners and oban_jobs_archive), which queue_keeper_check does not read.
  • Pro v1.7+ requires Oban 2.21+ and its v14 migration, which adds the suspended state (used for workflows and chains waiting on dependencies). queue_keeper_check ignores suspended jobs, which is the right thing: they are not due.
  • All queries are plain SELECTs on oban_jobs, so the read-only and least-privilege guarantees in SECURITY_REVIEW.md do not depend on the engine.
  • Pro v1.7 replaced several of Pro's own indexes and v1.8 dropped the old ones. The docs name Pro's indexes (unique, partition, workflow, chain, and Pro's old cancelled_at / discarded_at indexes); they do not say Oban core's indexes are changed. We have not verified that every core index queue_keeper_check relies on is still present on a Pro database; run EXPLAIN on the statements in SECURITY_REVIEW.md if query cost matters.

Where it can be wrong under Pro

Pro featureEffect on queue_keeper_check
Global limits and rate limits (global_limit, rate_limit per queue)Jobs deliberately held back by a limit stay available and age. :backlog can fire even though Pro is doing exactly what you configured, and :stalled can fire if the limit lets nothing start within the 60 s activity window (e.g. a slow rate limit). Raise backlog thresholds or exclude those queues.
Pro Pruner (Oban.Pro.Pruner, formerly Oban.Pro.Plugins.DynamicPruner)Its default rule keeps only the 1,000 most recent completed, cancelled or discarded jobs (by count, not age), and rules can differ per queue, worker or state. On a busy system that can be minutes of history, so :discarded and :cancelled spikes, :retry_storm with include_completed: true and :stalled's look-back see less than their windows, and :cron_missing can report a worker whose last run was pruned. Configure an age-based rule that covers your windows, or shrink the windows.
Archiving (Pruner rules with archive: true)Archived jobs move to oban_jobs_archive, which queue_keeper_check does not read. They count as pruned.
Pro Lifeline (Oban.Pro.Lifeline, formerly DynamicLifeline)Rescues orphans using producer records rather than a fixed rescue_after age, so real orphans are usually rescued long before :orphaned's 3600 s limit. Under Pro, :orphaned findings are more likely to be jobs that are genuinely still running. Lifeline also discards rescued jobs whose attempts are exhausted (unless retry_exhausted is set), which shows up in :discarded.
DynamicPartitioner (deprecated in Pro v1.8.1)Replaces oban_jobs with a table partitioned by state (finished states sub-partitioned by date, kept 3 days by default) under the same name; the original is renamed oban_jobs_old. Queries should still run, but index shapes on the partitions were not verified, so query cost is unknown. Pro's documented way off partitioning runs a second Oban instance in another prefix, so during that transition run the checker once per prefix (prefix:).
SnoozingPro's engine records snooze information in meta. We did not verify whether Pro's snooze changes attempt the way Oban core's does (core rolls the attempt back), so a snoozing worker could inflate :retry_storm (which counts attempt >= 2 for some states).
Async trackingPro bundles job acknowledgements and records outcomes with a short lag (documented as up to about 5 ms). Negligible at whole-second resolution.
Workflows, chains, batchesJobs waiting on dependencies are held in suspended (Pro v1.7+), ignored by the checker. How older Pro versions held such jobs was not checked.
Multiple Oban instances / prefixesAs with core Oban, one run checks one prefix.

Sources

All public documentation, read 2026-10-22:

If you run Pro and try queue_keeper_check, an issue with what you saw (findings that were wrong, query times, Pro and Oban versions) is the most useful contribution possible.