chore(deps): bump the Elixir and Rust trees, re-vendor Oban Pro 1.8 #11
Loading…
Reference in a new issue
No description provided.
Delete branch "chore/deps-bump-oban-pro-1-8"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
chore(deps): bump the Elixir and Rust trees, re-vendor Oban Pro 1.8
Every direct dependency now sits at its newest release that the graph allows,
the three Oban Pro packages are re-pulled from their official tarballs, and the
schema migration Oban Pro 1.8 requires is in place.
Elixir
mix deps.update --all: phoenix 1.8.13 → 1.8.14, phoenix_live_view1.2.11 → 1.2.12, swoosh 1.28.0 → 1.28.1, redix 1.8.2 → 1.9.2,
mox 1.3.1 → 1.3.2, dialyxir 1.4.7 → 1.4.8, sourceror 1.12.2 → 1.12.3,
spitfire 0.4.1 → 0.4.2, mint 1.10.0 → 1.10.1, ranch 2.2.1 → 2.3.0.
igniter0.8.4 andnx1.0.0 are the only remaining stragglers, and both areblocked by peers rather than by our own constraints: live_table 0.4.2 (already
latest) requires
igniter ~> 0.7.0, and axon 0.8.1 (already latest) requiresnx ~> 0.10.Oban Pro re-vendored
oban_pro1.7.0 → 1.8.0 (oban repo),oban_met1.1.0 → 1.3.1,oban_web2.12.5 → 2.13.0, andobanfloored at~> 2.24— the versionboth Pro packages now require.
vendor/trees are the published tarballs byte-for-byte(
diff -rclean). That drops two leftovers: the localelixirc_optionsedit 1.7.0's
mix.exsneeded (1.8.0 ships the equivalent upstream, so thevendored tree needs no patch) and
vendor/oban_met/.hex, stale metadataclaiming 1.1.0 that Mix never reads for a path dep.
/admin/obanboots against the new dashboard;mix depsresolves all threeat the new versions.
Oban Pro 1.8 migration
priv/repo/migrations/20260919191928_oban_pro_v1_8.exscallsOban.Pro.Migration.up(version: "1.8.0"): persisted Pruner rules(
oban_pruners), archived jobs (oban_jobs_archive), the workflowcompensation columns, the backfill index, and the drop of the
_oldindexesv1.7 left behind.
The upgrade guide offers a schemas/indexes split so the index half can run
CONCURRENTLY. Prod keeps at most a day of jobs (the Pruner runs daily withmax_age: {1, :day}), so the inline migration's lock window is short enoughthat the split isn't worth its extra moving parts — that reasoning lives in
the migration's
@moduledoc.Configuration keeps the 1.8 compatibility shims (
Oban.Pro.Engines.Smart,Oban.Pro.Plugins.DynamicLifeline). The guide marks the shorter names as anoptional rename and the shims emit no deprecation warnings, so this change
stays a dependency bump rather than a config rewrite.
Code changes
1.8 validates
:unique[:period]while expanding theuse Oban.Pro.Workermacro and now requires a literal integer or
{amount, unit}tuple, where 1.7accepted an unevaluated expression.
HrdpsGridWorkerpassed6 * 3600; itnow passes
21_600, with a comment naming the constraint so nobodyre-introduces the arithmetic. Every other
period:in the tree was already aliteral.
Rust
cargo updatemoves 107 crates, plus two major bumps:sqlx0.8 → 0.9 andtikv-jemallocator0.6 → 0.7. sqlx 0.9 deletes the combinedruntime-tokio-rustlsfeature, so the manifest asks forruntime-tokio+tls-rustlsinstead. No source changes were needed: every query in the crateis a
&'static strliteral, which is what 0.9's newSqlSafeStrbounddemands.
The highest MSRV among the moved crates is exactly 1.94.0 (the sqlx family),
matching the
rust:1.94-trixiebuild image. Checked crate-by-crate againstthe sparse index rather than assumed, since a single crate above 1.94 would
break the image build without failing anything locally.
Verification
cargo clippy --all-targets -- -D warningsclean;cargo test --releasegreen, including
scorer_golden::matches_elixir_golden_fixtureandjson_weights_golden.EXUNIT_MAX_CASES=8 make precommit: format,compile --warnings-as-errors,deps.unlock --check-unused,credo --strict(no issues) andxrefallpass. Tests land at 4901/4914 with 13 failures, identical to the baseline
measured before any of these changes: twelve
Wgrib2Testcases fail with:wgrib2_not_available(the binary isn't in the local shell) and oneHrrrClientTestcase needs NOAA over the network./health200,/admin/oban200, and thePropagationGridWorkercron fired and seededgrid_tasksunder the 1.8engine.
v1_0_0 … v1_8_0all ran in order rather than only the new delta.mix deps.auditandmix hex.audit: no vulnerabilities, no retiredpackages.
Notes
The vendored-path version cache bites on every future bump: Mix reads a path
dep's version from
_build/<env>/lib/<pkg>/ebin/<pkg>.appand rejects a newmix.exsrequirement as a mismatch untilmix deps.clean --build <pkg>runs.AGENTS.md's Dependencies section now records that, alongside the reminderthat an
oban_prominor always carries a required migration.Unprefixed
make precommitfails on a workstation whose Postgres is sharedwith other projects: the test pool is
EXUNIT_MAX_CASES + 4(40 by default on18 schedulers) against a
max_connectionsof 75, so concurrent pools exhaustthe server with
too_many_connections.EXUNIT_MAX_CASES=8, which is what CIuses, costs no wall time.
Every direct dependency now sits at its newest release that the graph allows, the three Oban Pro packages are re-pulled from their official tarballs, and the schema migration Oban Pro 1.8 requires is in place. ## Elixir `mix deps.update --all`: phoenix 1.8.13 → 1.8.14, phoenix_live_view 1.2.11 → 1.2.12, swoosh 1.28.0 → 1.28.1, redix 1.8.2 → 1.9.2, mox 1.3.1 → 1.3.2, dialyxir 1.4.7 → 1.4.8, sourceror 1.12.2 → 1.12.3, spitfire 0.4.1 → 0.4.2, mint 1.10.0 → 1.10.1, ranch 2.2.1 → 2.3.0. `igniter` 0.8.4 and `nx` 1.0.0 are the only remaining stragglers, and both are blocked by peers rather than by our own constraints: live_table 0.4.2 (already latest) requires `igniter ~> 0.7.0`, and axon 0.8.1 (already latest) requires `nx ~> 0.10`. ## Oban Pro re-vendored - `oban_pro` 1.7.0 → **1.8.0** (oban repo), `oban_met` 1.1.0 → **1.3.1**, `oban_web` 2.12.5 → **2.13.0**, and `oban` floored at `~> 2.24` — the version both Pro packages now require. - All three `vendor/` trees are the published tarballs byte-for-byte (`diff -r` clean). That drops two leftovers: the local `elixirc_options` edit 1.7.0's `mix.exs` needed (1.8.0 ships the equivalent upstream, so the vendored tree needs no patch) and `vendor/oban_met/.hex`, stale metadata claiming 1.1.0 that Mix never reads for a path dep. - `/admin/oban` boots against the new dashboard; `mix deps` resolves all three at the new versions. ## Oban Pro 1.8 migration `priv/repo/migrations/20260919191928_oban_pro_v1_8.exs` calls `Oban.Pro.Migration.up(version: "1.8.0")`: persisted Pruner rules (`oban_pruners`), archived jobs (`oban_jobs_archive`), the workflow compensation columns, the backfill index, and the drop of the `_old` indexes v1.7 left behind. The upgrade guide offers a schemas/indexes split so the index half can run `CONCURRENTLY`. Prod keeps at most a day of jobs (the Pruner runs daily with `max_age: {1, :day}`), so the inline migration's lock window is short enough that the split isn't worth its extra moving parts — that reasoning lives in the migration's `@moduledoc`. Configuration keeps the 1.8 compatibility shims (`Oban.Pro.Engines.Smart`, `Oban.Pro.Plugins.DynamicLifeline`). The guide marks the shorter names as an optional rename and the shims emit no deprecation warnings, so this change stays a dependency bump rather than a config rewrite. ## Code changes 1.8 validates `:unique[:period]` while expanding the `use Oban.Pro.Worker` macro and now requires a literal integer or `{amount, unit}` tuple, where 1.7 accepted an unevaluated expression. `HrdpsGridWorker` passed `6 * 3600`; it now passes `21_600`, with a comment naming the constraint so nobody re-introduces the arithmetic. Every other `period:` in the tree was already a literal. ## Rust `cargo update` moves 107 crates, plus two major bumps: `sqlx` 0.8 → 0.9 and `tikv-jemallocator` 0.6 → 0.7. sqlx 0.9 deletes the combined `runtime-tokio-rustls` feature, so the manifest asks for `runtime-tokio` + `tls-rustls` instead. No source changes were needed: every query in the crate is a `&'static str` literal, which is what 0.9's new `SqlSafeStr` bound demands. The highest MSRV among the moved crates is exactly 1.94.0 (the sqlx family), matching the `rust:1.94-trixie` build image. Checked crate-by-crate against the sparse index rather than assumed, since a single crate above 1.94 would break the image build without failing anything locally. ## Verification - `cargo clippy --all-targets -- -D warnings` clean; `cargo test --release` green, including `scorer_golden::matches_elixir_golden_fixture` and `json_weights_golden`. - `EXUNIT_MAX_CASES=8 make precommit`: format, `compile --warnings-as-errors`, `deps.unlock --check-unused`, `credo --strict` (no issues) and `xref` all pass. Tests land at 4901/4914 with 13 failures, identical to the baseline measured before any of these changes: twelve `Wgrib2Test` cases fail with `:wgrib2_not_available` (the binary isn't in the local shell) and one `HrrrClientTest` case needs NOAA over the network. - App boots in dev: `/health` 200, `/admin/oban` 200, and the `PropagationGridWorker` cron fired and seeded `grid_tasks` under the 1.8 engine. - The 1.8 migration chain was applied to a database created from scratch, so `v1_0_0 … v1_8_0` all ran in order rather than only the new delta. - `mix deps.audit` and `mix hex.audit`: no vulnerabilities, no retired packages. ## Notes The vendored-path version cache bites on every future bump: Mix reads a path dep's version from `_build/<env>/lib/<pkg>/ebin/<pkg>.app` and rejects a new `mix.exs` requirement as a mismatch until `mix deps.clean --build <pkg>` runs. `AGENTS.md`'s Dependencies section now records that, alongside the reminder that an `oban_pro` minor always carries a required migration. Unprefixed `make precommit` fails on a workstation whose Postgres is shared with other projects: the test pool is `EXUNIT_MAX_CASES + 4` (40 by default on 18 schedulers) against a `max_connections` of 75, so concurrent pools exhaust the server with `too_many_connections`. `EXUNIT_MAX_CASES=8`, which is what CI uses, costs no wall time.No findings. Reviewed the eight app-owned files in full; the 144
vendor/**files are upstream tarballs and were checked for integrity only, not line by line.Verified on the way through:
mix.exs/mix.lockconsistency:oban ~> 2.24is satisfied by the locked 2.24.1 (which this PR does not move), and the three path deps match their vendored trees (oban_pro 1.8.0, oban_met 1.3.1, oban_web 2.13.0).vendor/oban_webandvendor/oban_metare byte-for-byte the published hex tarballs (diff -ragainst repo.hex.pm; onlyhex_metadata.configis extra). oban_pro itself could not be checked against its tarball, that repo needs the licensed credentials.1.7.0-schemas,1.7.0-indexesgives index 4 < 5, so only V180 runs), and everyup_funthe newchange_functionscall re-runs on older versions is aCREATE OR REPLACE, so the replay is idempotent.DynamicLifelinekeepsrescue_intervalas:periodandto_timeout(second: 30)is still read as ms (same 30s), and theEngines.Smartshim omits only the four optionalOban.Enginecallbacks, which Oban'swith_compatible_enginefalls back toOban.Engines.Basicfor.rust:1.94-trixieinrust/prop_grid_rs/Dockerfilestill builds.tls-rustlsis a real sqlx 0.9 feature and resolves to ring + webpki-roots, the same provider stack as the oldruntime-tokio-rustls.One non-code nit, not blocking:
mix.exspins{:nx, "~> 0.13"}, and a two-segment~>means< 1.0.0, so nx is excluded by our own constraint as well as by axon's~> 0.10. Bumping axon alone will not reach nx 1.0.0.