Repository navigation
pkgs/id: test_the_lock_has_no_sqlite_with_logsync_wired fails on main — Cargo.lock sqlx-sqlite edge not in the test's allow-list #3930
Description
Failing on main (verified 2026-11-01, lane D worker): store_traits::tests::test_the_lock_has_no_sqlite_with_logsync_wired in pkgs/id panics at src/store_traits.rs:701:
sqlx-sqlite depends on libsqlite3-sys: SQLite is back in the shipped build (see vendor/README.md)
Evidence it is pre-existing, not a recent regression from the nearest merge:
- The test reads only
pkgs/id/Cargo.lock+pkgs/id/Cargo.toml(viaCARGO_MANIFEST_DIR) and asserts no package outside the allow-list has a SQLite-family edge. The committedCargo.lockat 33aefa7 (parent of the PR feat(id): region-seam handoff journal foundation (#3900) #3922 merge) already contains thesqlx-sqlite0.9.0 package whose dependencies includelibsqlite3-sys— the exact edge the test rejects (thesqlxfacade's optional backend packages are recorded in the lock even when inactive). - The test FAILS identically at 33aefa7 and at post-merge main (876b402) in clean worktrees on the laptop; PR feat(id): region-seam handoff journal foundation (#3900) #3922 changed zero Cargo files.
- Repro:
cargo test -p id --lib test_the_lock_has_no_sqlite_with_logsync_wiredin pkgs/id at either commit → 0 passed, 1 failed, panic at store_traits.rs:701.
What a fix looks like: either the test's allow-list learns the sqlx facade shape (a package whose sqlite edge is optional/inactive in the default-feature graph — the test's second half already asks cargo tree for the shipped graph, so the lock-edge half may need the same treatment for sqlx → sqlx-sqlite), or the lock is regenerated so the inactive backend packages are absent. The test's own doc comment says the lock records optional edges even when inactive, which is exactly the sqlx-sqlite case.
Related: #3160 (closed) previously tracked lib-test failures on main including a rusqlite guard.
Acceptance criteria
-
cargo test -p id --lib test_the_lock_has_no_sqlite_with_logsync_wiredpasses on current main. - The fix addresses the lockfile-vs-allow-list mismatch directly (allow-list learns the sqlx facade's inactive backend packages, or the lock no longer records them) without weakening the test's actual guarantee: no SQLite edge in the shipped build's active dependency graph.
- The test still fails if a real SQLite dependency is introduced into the shipped graph (negative check).
Activity
dezren39 commentedon Nov 1, 2026
Intake review
Fleet monitor intake enrichment (protocol §5), 2026-11-01.
Still live: checked merged PRs and recent work in this area — no merged PR explicitly resolves this issue, and the filing evidence is from current main today. Not closing.
Related: Related: PR #3922 explicitly did NOT introduce this (zero Cargo files changed; the test fails identically at its parent 33aefa7). No merged PR resolves it. Neighbourhood: issue #3923 / issue #3951 are separate id build breakages on current main.
Risks / notes: The trap is weakening the guard: the test exists to keep SQLite out of the shipped build. A fix that simply allow-lists sqlx-sqlite unconditionally would pass while defeating the guard if the backend ever activates.
Suggested approach: Teach the allow-list to distinguish lockfile-recorded inactive optional backends from active graph edges (or prune the inactive packages from the lock), and keep a negative check that a real SQLite edge still fails the test.
Labels normalized (kind/source/status/priority/effort/app as applicable) and
meta/enrichedapplied; an## Acceptance criteriasection was appended to the issue body (original body preserved verbatim above it).developing-today commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 40 (priority/normal). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 3, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 3, 2026
🤖 Agent note · done
a0b54cf679578a9527840eaa0499255c1848b2ed,pkgs/id/Cargo.lockcontains zerosqlx-sqliteentries. Commitbc86b303a08ac7a725da65b2aa4f12ecde4b60d9— "fix(id): re-resolve the lock without the vendored member graph (build(id): two test failures at main — stale shell-contract v1.3 expectation + sqlx-sqlite back in the lock (blocks code#3720 fold) #4015)" ("Gone are the sqlx family (sqlx, sqlx-core, sqlx-macros, sqlx-macros-core, sqlx-mysql, sqlx-postgres, sqlx-sqlite)") — is an ancestor of current main. That is the issue's own second fix option: the lock no longer records the inactive backend packages.cargo test -p id --lib test_the_lock_has_no_sqlite_with_logsync_wired→test result: ok. 1 passed; 0 failed; 2028 filtered out.already_done. No follow-up fix task needed.