---
name: libsqlite3-sys-artifact-corruption
description: "A vendored-dep build artifact corrupts IN PLACE mid-session and reads as a real build break — cargo clean -p libsqlite3-sys, don't debug your own change"
metadata: 
  node_type: memory
  type: reference
  originSessionId: e28594ae-d005-4f54-998f-306a9986a631
  modified: 2026-08-04T02:03:18.555Z
---

`cargo`/`xtask` builds on this node intermittently fail with a **corrupt
`libsqlite3-sys` artifact**:

```
error: could not compile `libsqlite3-sys` (lib)
  include!(concat!(env!("OUT_DIR"), "/bindgen.rs"));
  ^^^ (the include! line is the reported span)
```

**Fix:** `cargo clean -p libsqlite3-sys` (removed 74 files / 73.1 MiB in the
observed case), then re-run. Green immediately after.

**SECOND SIGNATURE, same class (2026-08-03, todlando, knock145 pool).** Do not
match this fault on the `include!`/bindgen span alone — it also presents as the
ARCHIVE step failing:

```
error occurred in cc-rs: command did not execute successfully (status code exit code: 1):
"...\MSVC\...\bin\HostX64\x64\lib.exe" "-out:...\libsqlite3-sys-<hash>\out\libsqlite3.a" ...
error: command `cargo test --no-run ... --package spt --bins` exited with code 101
```

Same package, same in-place corruption, different span — so the tell is the
PACKAGE plus a build you did not touch, never the reported line. Note the exit:
**101 in the BUILD means zero tests ran**, which is a silence that reads as a
test result if you only look at the exit code. Say "unverified", not "failed".

The same pool had passed `cargo check -p spt --all-targets` (exit 0) ~20 min
earlier and a `cargo nextest --test <int>` build succeeded minutes LATER in that
same pool without any clean — another in-place corrupt-and-recover, and the
recovery is why "it went away" must never close this class.

**Why this is worth a memory rather than a shrug:** it is a **recurring
instrument-class fault**, and its signature reads exactly like a real build
break, which is the combination that eats a gate slot and sends you debugging
your own change.

Occurrences on 2026-07-31, both on HFENDULEAM:
1. doyle's scratch target, during the W5 wave gate — he RCA'd it as gate-harness,
   never the wave.
2. my redirected scratch target (`CARGO_TARGET_DIR` under the session
   scratchpad), ~20 min later. **That same target had compiled the crate CLEAN
   earlier in the same session**, so it corrupted *in place between two runs* —
   not a stale-checkout or first-build problem.

Two independent target dirs, same dep, same signature, one corrupting
mid-session. Suspect concurrent cargo processes sharing/racing artifacts on this
node (live agents build constantly here — see
[[live-agents-lock-target-debug-spt-exe]]).

**Discipline:** when a vendored dep you did not touch fails to compile, clear
that ONE package and retry BEFORE suspecting your change — but do clear it and
get a real green, never declare the red benign from its shape alone
([[instrument-soundness-guards]]: a gate whose failure signature matches the
fault it guards is broken).

**Pinned 2026-07-31 (todlando), before anyone mis-credits a fix:** the OOM
stopgap `[build] jobs = 4` in decid's cargo config bounds parallelism WITHIN one
cargo invocation only — it does NOT bound concurrent cargo PROCESSES across
agents on this node, which is the racing hypothesis for this corruption. If the
corruption stops recurring after jobs=4 landed, that is CORRELATION, not the
fix; the hypothesis was never reproduced in either direction and stays open.