chore(deps): update all dependencies to latest and restore modern nightly compatibility - #13
Conversation
Bumps [serde_with](https://github.com/jonasbb/serde_with) from 3.17.0 to 3.22.0. - [Release notes](https://github.com/jonasbb/serde_with/releases) - [Commits](jonasbb/serde_with@v3.17.0...v3.22.0) --- updated-dependencies: - dependency-name: serde_with dependency-version: 3.22.0 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
|
We need to update all dependencies to latest versions and fix all errors. |
|
🤖 AI Work Session Started Starting automated work session at 2026-09-16T07:57:44.167Z The PR has been converted to draft mode while work is in progress. This comment marks the beginning of an AI work session. Please wait for the session to finish, and provide your feedback. Runtime: solve |
Two build failures broke CI on current Rust nightly:
- ethnum 1.5.2 built TryFromIntError with unsafe { mem::transmute(()) }.
TryFromIntError is no longer zero-sized, so this fails with E0512
("cannot transmute between types of different sizes"). ethnum 1.5.3
constructs it via u8::try_from(-1i8).unwrap_err() instead. Bump the
lockfiles of both the benchmark crate and the WASM module, which reach
ethnum through spacetimedb-sats / spacetimedb-memory-usage.
- std::ops::Try::Residual gained a Residual<Self::Output> bound, so
platform-data's Flow (its own residual) failed with E0277. Add the
matching impl Residual<()> for Flow and enable try_trait_v2_residual.
…versions cargo update across the benchmark crate, which also clears three Dependabot alerts: - anymap 0.12.1 (CRITICAL, unpatched "incorrect cast") is dropped in favour of anymap3 1.1.0, pulled in by spacetimedb-sdk 2.0.3 -> 2.10.1. - protobuf 2.28.0 -> 3.7.2 (uncontrolled recursion), via prometheus 0.14. - serde_with is already on 3.22.0 from the base commit. spacetimedb-sdk 2.10 requires RemoteModule: Debug and renames the generated table module, so src/module_bindings is regenerated with `spacetime generate` 2.10.1 (link_table -> links_table, LinkTableAccess -> LinksTableAccess) and the import in spacetimedb_impl.rs follows. This also aligns the client SDK with the server version CI installs.
…sions - spacetime-module: rand 0.9.2 -> 0.9.5, clearing the Dependabot advisory for rand being unsound with a custom logger using rand::rng() (vulnerable >= 0.9.0, < 0.9.3). spacetimedb 2.0.3 -> 2.10.1 keeps the module in step with the client SDK; the generated bindings are byte-identical, so src/module_bindings needs no change. - root package: tokio 1.48 -> 1.53.1 and the rest of the tree. Verified: cargo fmt --check, cargo clippy --all-targets, and cargo test pass in both the root package and rust/ (13 tests against a local SpacetimeDB 2.10.1 server).
criterion was pinned at =0.3.6 since the first commit with no recorded reason. It is the only remaining source of atty 0.2.14, which has an open unpatched advisory (potential unaligned read) and no fixed release. criterion 0.8 dropped atty, so the pin is the last blocker. cargo_bench_support has to be requested explicitly because it stopped being implied by default-features = false in criterion 0.5. The suite only uses bench_with_input + iter_custom, which are unchanged, and the workflow's CLI flags (--output-format bencher, --sample-size, --warm-up-time, --measurement-time, --nresamples) all still apply. Verified by running the full 35-benchmark suite against a local SpacetimeDB server; output is byte-compatible with the bencher format.
out.py expected `test <benchmark>/<operation>/<variant>/<size>`, but the
benchmarks build ids as BenchmarkId::new("<operation>/<variant>", <size>),
which Criterion renders with three slash-separated components. The regex
therefore matched nothing: out.py printed "No benchmark data found" and
exited 0, so the charts were never produced and the workflow uploaded (and
on main, committed) an artifact set with no images. This is independent of
the criterion upgrade -- the ids never had a fourth component.
Also register the file-backed variants added alongside the non-volatile
benchmarks; they were measured but had no label or colour, so they were
dropped from the charts even once parsing worked.
Adds test_out_py.py, which fails against the previous regex (4 of 5 tests)
and passes now, and runs it from the Test job.
main already fixed the Criterion bencher parsing (rust/out.py) and added rust/test_out.py plus a dedicated results-pipeline CI job, so the equivalent changes from this branch are dropped in favour of main's versions.
The pin at nightly-2026-04-14 worked around E0512 in ethnum and E0277 in the patched platform-data. Both are now fixed at the source (ethnum 1.5.3 and an explicit `impl Residual<()> for Flow`), so the pin can move forward. It stays a dated nightly rather than a rolling one, so the drift of issue #14 cannot recur.
Working session summaryDone. PR #13 is out of draft, mergeable, and all 16 checks pass: #13 What landed Root cause of the two failing checks was Rust nightly drift, not the
All three lockfiles were then refreshed, clearing all five Dependabot alerts ( Rest of the working session summary (1 KB)This summary was automatically extracted from the AI working session output. |
🤖 Solution Draft LogThis log file contains the complete execution trace of the AI solution draft process. 💰 Cost: $8.539735📊 Context and tokens usage:Claude Opus 5: (2 sub-sessions)
Total: (3.2K new + 181.1K cache writes + 9.7M cache reads) input tokens, 74.2K output tokens, $8.539736 cost 🤖 Models used:
📎 Log file uploaded as Gist (4304KB)Now working session is ended, feel free to review and add any feedback on the solution draft. |
🎉 Auto-mergedThis pull request has been automatically merged by hive-mind.
Auto-merged by hive-mind with --auto-merge flag |
Closes #13.
Started as Dependabot's
serde_with 3.17.0 -> 3.22.0bump; extended per the request in the issue: "We need to update all dependencies to latest versions and fix all errors."What was broken
The two CI failures on this branch were not caused by the
serde_withbump. They were Rust nightly drift, andmainhad worked around them by pinning the toolchain tonightly-2026-04-14(see the fragment added in #15). This PR fixes both at the source and moves the pin forward.1.
error[E0512]inethnum1.5.2ethnum 1.5.2builtcore::num::TryFromIntErrorwithunsafe { mem::transmute(()) }.TryFromIntErroris no longer zero-sized, so the transmute is rejected. Upstream1.5.3constructs it viau8::try_from(-1i8).unwrap_err()instead — the fix is a lockfile bump inrust/Cargo.lockandrust/spacetime-module/Cargo.lock.2.
error[E0277]in the vendoredplatform-dataNightly's
Try::Residualgained aResidual<Self::Output>bound (library/core/src/ops/try_trait.rs). The vendoredFlowdeclarestype Residual = Flowbut never said whichTrytype it reconstructs.Flowis its own residual and itsOutputis(), so:plus the
try_trait_v2_residualfeature gate, sinceResidualis exported under a gate separate fromtry_trait_v2. Documented inrust/doublets-patched/PATCHES.mdalongside the existing patches.Dependency updates
All three lockfiles refreshed. This clears all five open Dependabot alerts:
serde_with 3.17.0→3.22.0anymap 0.12.1→anymap3 1.1.0protobuf 2.28.0→3.7.2rand 0.9.2→0.9.5,0.8.6→0.8.8>=0.9.0,<0.9.3attyremovedspacetimedb-sdk/spacetimedb2.0.3→2.10.1criterion =0.3.6→0.8ethnum/attytransitivestokio 1.48.0→1.53.1,syn 2.0.111→3.0.5Two follow-on changes were required by those upgrades:
0.8needsfeatures = ["cargo_bench_support"]spelled out — criterion stopped implying it underdefault-features = falsein 0.5.spacetimedb-sdk 2.10.1boundsRemoteModuleonDebug, which produced 30 ×E0277against the checked-in bindings.rust/src/module_bindings/was regenerated withspacetime generate2.10.1: the table module is nowlinks_table(LinksTableAccess/LinksTableHandle) rather thanlink_table, and the types carryDebugderives.rust/src/spacetimedb_impl.rsfollows the new import path. Regenerating from the WASM built by 2.10.1 and by 2.0.3 produces byte-identical output, so the change is purely the SDK's codegen, not a module schema change.Toolchain pin moved to
nightly-2026-09-16nightly-2026-04-14existed only to dodge the two errors above. With both fixed,rust/rust-toolchain.tomland.github/workflows/rust-benchmark.yml(kept in sync) move tonightly-2026-09-16=1.100.0-nightly (215a8af4b 2026-09-15). It is still a dated nightly, not a rolling one, so the drift of #14 cannot recur — and moving it is what makes CI actually exercise the two fixes, instead of never reaching the code paths that used to break.Verification
Reproduction of the original failure:
cargo buildinrust/on any nightly newer than roughly 2026-05 fails with theE0512above; onceethnumis bumped, theE0277surfaces behind it.The full
testjob was reproduced locally end-to-end against the merged tree on the new pin:The reporting pipeline was also run end-to-end, because the
out.pybencher regex onmainis tuned to criterion 0.3.6's output and criterion 0.8 is a large jump. It parses cleanly — all 35 measurements, all 5 backends:(quick-mode numbers,
BENCHMARK_LINK_COUNT=10— for pipeline validation, not for publication.)Note on
rust/out.pyThis branch originally carried its own fix for the bencher parser and a
rust/test_out_py.py.mainfixed the same bug more thoroughly in #15 (rust/out.pyrewrite,rust/test_out.py, a dedicatedresults-pipelinejob), so the merge drops this branch's versions in favour ofmain's. No parser changes remain here.