cargo test --workspace is red on main: unsatisfiable testcontainers conflict (DEBT-REGISTER CI-1 names the wrong cause)

[hyperpolymath]

What

cargo test --workspace is red on main, and has been for some time, for
a reason that is not what DEBT-REGISTER CI-1 says it is.

The actual cause, measured 2026-09-22

integration/Cargo.toml requires both:

• testcontainers ^0.28
• testcontainers-modules ^0.15, which itself requires testcontainers ^0.27

^0.27 and ^0.28 are disjoint under Cargo's semver rules for 0.x releases.
This is unsatisfiable at the manifest level, so no Cargo.lock can fix it,
cargo fails during dependency resolution, and no crate in the workspace is
ever compiled — including clients/rust/hypatia-client.

⚠ The debt register currently records the wrong cause

DEBT-REGISTER CI-1 states the failure is "a stale
dtolnay/rust-toolchain@stable pin … 13 jobs die at Set up job".

That is no longer true. The jobs start fine; they die at cargo resolution,
which is a later phase with a different fix. Anyone acting on the register
today would bump a toolchain pin and find nothing changed.

Consequence for the wire contract

The five Rust tests that pin the connector enum (count_is_sixteen,
wire_ids_are_stable, names_round_trip, from_id_round_trip,
port_layout_matches_v_lang) do not execute in CI and have not for as long
as this conflict has existed. They were verified green for PR #811 only by
extracting the crate into a standalone workspace: 5 passed, 0 failed.

Acceptance criteria

• cargo test --workspace --locked exits 0 on main, and its output shows
  hypatia-client's five tests actually running — a non-zero
  denominator, not a skip.
• DEBT-REGISTER CI-1 is corrected to name the resolution conflict, with
  the old toolchain-pin explanation struck rather than deleted, so the
  record shows it was wrong rather than appearing never to have said it.
• The fix is at the manifest level (align the two crates on one
  testcontainers major, or drop one), not a [patch] — a patch makes
  local and CI resolve differently.
• A mutant confirms the tests have teeth once they run: change one wire id
  in connector_generated.rs, confirm wire_ids_are_stable goes red.

[hyperpolymath]

Blast radius is much larger than this issue records — and it was invisible until today

#824 fixed a duplicate with: key that had startup-killed six workflows (conclusion: failure with jobs = 0 — no jobs, no log, no check-run). With those workflows running again, this testcontainers conflict is now visible in 10 failing jobs across 4 workflows, where previously it surfaced in only a couple:

Workflow	Job	First failing step
ci.yml	Rust Check & Clippy	Run cargo check ✔ confirmed
ci.yml	CI Status	aggregator
tests.yml	Build Test Images	Build hypatia image ✔ confirmed
tests.yml	E2E — Rust CLI Scan	Build Rust CLI
tests.yml	stress-test	Build release
tests.yml	criterion + baseline gate	Run criterion benches (quick mode)
tests.yml	Integration Status	aggregator
quality.yml	Build AsciiDoc	Generate Rust API documentation ✔ confirmed
security-policy.yml	Generate Rust SBOM	Generate CycloneDX SBOM
security-policy.yml	Container Security (Trivy)	Build container image

✔ = log read directly and the testcontainers error confirmed. The unmarked rows fail at the same class of step (a cargo build) and are almost certainly the same cause, but I did not open each log, so I am not asserting it.

The error, verbatim:

error: failed to select a version for `testcontainers`.
    ... required by package `testcontainers-modules v0.15.0`
    ... which satisfies dependency `testcontainers-modules = "^0.15"` of package `hypatia-integration-tests v0.1.0`
all possible versions conflict with previously selected packages
    ... which satisfies dependency `bollard = "^0.21.0"` of package `testcontainers v0.28.0`
    ... which satisfies dependency `testcontainers = "^0.28"` of package `hypatia-integration-tests v0.1.0`
failed to select a version for `testcontainers` which could resolve this conflict

So the conflict is between testcontainers-modules ^0.15 and testcontainers ^0.28 (via bollard ^0.21.0), both declared by integration/Cargo.toml. A single workspace member is blocking cargo check for the whole workspace — which is why documentation generation, SBOM generation and container builds all fail too, none of which has anything to do with integration testing.

Confirms this issue's title claim

This issue already says DEBT-REGISTER CI-1 names the wrong cause. That is now independently confirmed: #823 removed the stale dtolnay/rust-toolchain@6c977a6c (ref: stable) orphan entry from actions.lock that CI-1 blames, and the Rust jobs still fail — with the resolver error above, not a toolchain error. CI-1 and CLAUDE.md Known Gap 4 should be amended to point here.

Suggested next step

Because the failure is a resolver conflict in one workspace member, the cheapest containment is to make the whole workspace resolvable again (align testcontainers / testcontainers-modules versions in integration/Cargo.toml, or exclude integration from the default workspace members) — that alone would return ~9 of the 10 jobs above to green without touching any of their own logic.

🤖 Generated with Claude Code

https://claude.ai/code/session_0113HQM9LVGkNCzU1WwkJZSV