CI flake: Test Suite / typescript::insert_call_uuid_v4, typescript::insert_call_uuid_v7,...

[clockwork-labs-bot]

Detected by CI Gremlin after a failed GitHub Actions attempt succeeded on rerun.

Tests:

• typescript::insert_call_uuid_v4
• typescript::insert_call_uuid_v7
• typescript::insert_caller_connection_id
• typescript::insert_caller_identity
• typescript::insert_connection_id

Error:
thread 'typescript::insert_call_uuid_v4' (153616) panicked at crates/testing/src/sdk.rs:175:5:
called Result::unwrap() on an Err value: PoisonError { .. }

Failed job runs:

• https://github.com/clockworklabs/SpacetimeDB/actions/runs/32949572715/job/98118575600 (Test Suite, attempt 1 -> 2)

Timeout detection:

• none

Context:

• none

[clockwork-labs-bot]

Diagnosis for the exact linked job/attempt: run 32949572715, job 98118575600, Test Suite, attempt 1. The run was for PR #5793 (tien/feat/egress-mcp-root), head SHA 6d3aa8bc0f028597b17b845d9477540aa804744c; the checked-out merge commit in the job was a37be70930e7a513bacc457279ecfdadd5033ce0.

The ticket title points at typescript::insert_call_uuid_v4 and nearby TypeScript SDK tests, but those are secondary failures. The first clear root failure in the exact job is earlier, starting at rust::insert_vec: the SDK harness successfully spawned a server and published the module, then the client cargo run failed because Cargo could not read the workspace lockfile:

thread 'rust::insert_vec' ... panicked at crates/testing/src/sdk.rs:115:9:
(running): Error running "cargo run -- insert-vec": exited with non-zero exit status exit status: 101. Output:
error: failed to read file: /home/runner/actions-runner/_work/SpacetimeDB/SpacetimeDB/Cargo.lock

Caused by:
  stream did not contain valid UTF-8

After that, many later SDK tests failed either with the same Cargo.lock UTF-8 error or with:

called `Result::unwrap()` on an `Err` value: PoisonError { .. }

The PoisonError comes from the memoized SDK harness mutex in crates/testing/src/sdk.rs; once one test panics while holding that compile/generate cache lock, later tests that reuse the cache can fail immediately on the poisoned mutex. The job summary shows a cascade, not isolated TypeScript SDK behavior regressions: 180 passed; 106 failed; 4 ignored.

Root cause visible in this exact attempt: the checked-out workspace Cargo.lock became unreadable as UTF-8 during the Test Suite, causing client cargo run invocations to fail and poisoning the shared SDK-test cache. I do not see evidence in this job that the named TypeScript reducer tests are the primary failures.

Suggested updated title: CI flake: Test Suite Cargo.lock invalid UTF-8 poisons SDK test cache

Duplicate analysis:

• Similar PoisonError surface tickets exist: CI flake: Test Suite / typescript::delete_uuid, typescript::indexed_simple_enum, typescript::insert_call_uuid_v4,... #5412, CI flake: Test Suite / typescript::indexed_simple_enum, typescript::insert_call_uuid_v4,... #5413, and CI flake: Test Suite / typescript::insert_call_uuid_v4, typescript::indexed_simple_enum,... #5499. They are not close duplicates for this exact job because their diagnosed roots were different: CI flake: Test Suite / typescript::delete_uuid, typescript::indexed_simple_enum, typescript::insert_call_uuid_v4,... #5412/CI flake: Test Suite / typescript::indexed_simple_enum, typescript::insert_call_uuid_v4,... #5413 involved Binaryen/wasm-opt or transient TypeScript dependency/import failures, and CI flake: Test Suite / typescript::insert_call_uuid_v4, typescript::indexed_simple_enum,... #5499 involved a Node/V8 unreachable code abort.
• I searched exact and fallback terms including stream did not contain valid UTF-8, failed to read file Cargo.lock, Cargo.lock UTF-8 Test Suite, and PoisonError sdk.rs across the org.

Top duplicate candidate: none close enough to mark as duplicate. Leaving this open.

Caveat: I diagnosed only the exact linked job/attempt. Duplicate search was broader, but I did not use rerun attempts to infer this attempt's root cause.