Build Examples has failed on main since 2026-09-01: the example has no Cargo.lock, so CI re-resolves and a transitive MSRV bump broke it #274

Build Examples has failed on main since 2026-09-01, and it will keep failing on every PR until the example is pinned. No code change caused it.

The failure

Building Wasmtime integration example
     Locking 310 packages to latest compatible versions
error: rustc 1.94.0 is not supported by the following packages:
  cranelift-assembler-x64@0.135.1 requires rustc 1.95.0

.github/workflows/rust.yml pins RUST_VERSION: 1.90.0; a transitive dependency raised its MSRV to 1.95.0.

Why it broke with no commit

That Locking 310 packages to latest compatible versions line is the whole story. examples/wasmtime-loader has no committed Cargo.lock:

$ git ls-files examples/wasmtime-loader | grep -c Cargo.lock
0

So CI re-resolves the entire example dependency graph on every run. Any transitive MSRV bump anywhere in 310 packages breaks the build, at a time nobody chose, on a commit that did not touch it. It builds fine locally on a newer toolchain, which is what makes it confusing to hit.

Confirmed pre-existing

main   run 33456180288  2026-09-01   Build Examples: failure   (same error)
main   run 32516794682               Build Examples: success
main   run 32516293734               Build Examples: success

The two older runs predate the upstream bump.

Suggested fix

Commit examples/wasmtime-loader/Cargo.lock. The workspace pins its own dependencies; the example is the one place resolution is left floating, and it is also the place with the largest graph. A lockfile makes the upgrade a reviewed diff instead of a surprise, and dependabot can then bump it deliberately.

If the example is meant to demonstrate building against current crates, the alternative is -Zminimal-versions-style pinning or simply raising RUST_VERSION — but the version should still be a decision, not a resolution artifact.

Related, in the methodology sense: pulseengine.eu#180 argues that a value your build depends on must be derived or pinned, never left to drift. This is that rule applied to dependency resolution — and the failure mode it predicts is exactly what happened: the breakage is detected but not attributed, so it reads as "my PR broke the examples."

Impact right now

It blocks #273 (and every other PR) on a check unrelated to the change under review.