Move pending Oban work into Belay, safely.
# See what would happen (no writes):
mix belay.migrate_oban --url postgres://localhost/my_app
# Do it (stop Oban's producers first):
mix belay.migrate_oban --url postgres://localhost/my_app --execute
# Renamed a worker during the port?
mix belay.migrate_oban --url ... --execute \
--map "MyApp.OldWorker=MyApp.NewWorker"Migrates available/scheduled/retryable rows only. executing rows
are flagged and skipped (they may be live on an Oban node — drain first).
Terminal rows are history, not work: keep them where they are
(ALTER TABLE oban_jobs RENAME TO oban_jobs_archive) until retention
lapses. Re-runs are idempotent via meta.migrated_from_oban_id.
Run this task from your application (mix belay.migrate_oban inside
the app) so worker modules are loadable — the analyzer verifies each
pending worker is actually ported to Belay.Worker and refuses to
migrate ones that aren't (override with --force).
Uniqueness is the one thing that cannot migrate mechanically: Oban keeps
unique policy on workers, Belay keeps unique keys on rows. The
report lists affected workers; re-declare unique: at their insert sites.