CI flake: Smoketests (Windows 2/4) / cluster::cli::publish::cli_can_publish_breaking_change_with_delete_data_flag

[clockwork-labs-bot]

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

Tests:

• cluster::cli::publish::cli_can_publish_breaking_change_with_delete_data_flag

Error:
thread 'cluster::cli::publish::cli_can_publish_breaking_change_with_delete_data_flag' (6448) panicked at crates\smoketests\tests\cluster\cli\publish.rs:68:10:
called Result::unwrap() on an Err value: spacetime ["publish", "--module-path", "C:\actions-runner\_work\SpacetimeDB\SpacetimeDB\modules\module-test", "--server", "http://127.0.0.1:50214", "--yes=remote",...

Failed job runs:

• https://github.com/clockworklabs/SpacetimeDB/actions/runs/34253018158/job/102161276745 (Smoketests (Windows 2/4), attempt 1 -> 2)

Timeout detection:

• none

Context:

• none

[clockwork-labs-bot]

Diagnosis for the exact linked job/attempt: run 34253018158, job 102161276745, Smoketests (Windows 2/4), attempt 1.

GitHub's job API reports the linked job as run_attempt: 1, matching the ticket's failed attempt 1 -> 2 rerun. The workflow was CI for PR #5884 (Version bump 2.10.1), head SHA f5a76e0a9cf9c92e0b557618d6134b668262be71, on Windows runner ghr-1c5ccc9f.

The failing test was cluster::cli::publish::cli_can_publish_breaking_change_with_delete_data_flag. The standalone server started quickly and became HTTP-ready, then the first spacetime publish command ran for about 4.6s before returning an error. The useful failure signature is inside that publish stderr:

error: could not compile `spacetimedb-sats` (lib)
Caused by:
  process didn't exit successfully: `...rustc.exe ... --target wasm32-unknown-unknown ...` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)
Error: command ["cargo", "build", "--config=net.git-fetch-with-cli=true", "--target=wasm32-unknown-unknown", "--release", "--message-format=json-render-diagnostics"] exited with code 101

The smoketest then panicked at crates\smoketests\tests\cluster\cli\publish.rs:68:10 because it unwrapped the failed spacetime publish result. Root cause visible in this exact attempt: Windows rustc.exe crashed with STATUS_ACCESS_VIOLATION while compiling spacetimedb-sats for the WASM target during module publish. This is a Windows Rust/toolchain/compiler crash surfaced through the publish smoketest, not an assertion failure in the delete-data publish behavior itself.

Suggested updated title: CI flake: Windows rustc STATUS_ACCESS_VIOLATION compiling spacetimedb-sats

Duplicate analysis:

• Top duplicate candidate: none found.
• Similar ticket CI flake: Upload build artifacts (Windows) #5799 is not a match: it tracks a Windows artifact/log-fetch/runner-loss style failure, not a rustc.exe STATUS_ACCESS_VIOLATION while compiling spacetimedb-sats for wasm32-unknown-unknown.
• I searched exact and fallback terms including cli_can_publish_breaking_change_with_delete_data_flag, breaking-change-delete-data, You are not logged in, STATUS_ACCESS_VIOLATION rustc.exe, 0xc0000005 spacetimedb-sats, wasm32-unknown-unknown STATUS_ACCESS_VIOLATION, git_diff_stats_free STATUS_ACCESS_VIOLATION, Windows rustc access violation wasm32 unknown unknown, and spacetimedb sats rustc access violation.

Leaving this open because I did not find a close duplicate candidate.