CI flake: segfault in wasm-opt?

[clockwork-labs-bot]

Created by CI Gremlin from a manually supplied failed GitHub Actions job.

Tests:

• cpp_procedures::http_err
• cascading SDK failures after the shared module cache/lock was poisoned (208 failed total)

Error:
thread 'cpp_procedures::http_err' (126962) panicked at crates/testing/src/modules.rs:190:10:
Module compilation failed: Failed to build C++ project

Caused by:
0: failed running cmake
1: command ["cmake", "--build", "build", "--config", "Debug", "--parallel"] exited with code 2

Failed job runs:

• https://github.com/clockworklabs/SpacetimeDB/actions/runs/27650845594/job/81774964286 (Test Suite, attempt manual -> n/a)

Context:

• Manual failed-job flake ticket.
• Job URL: https://github.com/clockworklabs/SpacetimeDB/actions/runs/27650845594/job/81774964286
• Run: 27650845594
• Job: 81774964286

[clockwork-labs-bot]

I dug through the specific failed job Zeke linked: run 27650845594, job 81774964286, attempt 1.

Root failure:

emcmake: cmake -S . -B build ... in directory .../modules/sdk-test-procedure-cpp
[100%] Linking CXX executable lib.wasm
em++: error: '.../wasm-opt --strip-target-features --post-emscripten -O2 ... lib.wasm -o lib.wasm ...' failed (received SIGSEGV (-11))

That wasm-opt process is Binaryen, invoked by Emscripten during the final em++ link/optimize step. So the root error is not the Rust SDK assertion and not an SDK behavior failure. The C++ module build reached the final lib.wasm link step, then the optimizer segfaulted.

The visible Rust panic is just the test harness surfacing that failed module build:

thread 'cpp_procedures::http_err' panicked at crates/testing/src/modules.rs:190:10:
Module compilation failed: Failed to build C++ project
Caused by:
    0: failed running `cmake`
    1: command ["cmake", "--build", "build", "--config", "Debug", "--parallel"] exited with code 2

The 208 failed total is mostly fallout. The SDK test harness memoizes module compilation by module name because these builds are expensive and some toolchains do not tolerate concurrent builds in the same project folder. Once sdk-test-procedure-cpp failed to compile, every SDK test that needed that shared module reported failure too.

My read: this ticket should track an Emscripten/Binaryen wasm-opt SIGSEGV while building modules/sdk-test-procedure-cpp. The useful root signature is em++: error: ... wasm-opt ... failed (received SIGSEGV (-11)), not cpp_procedures::http_err or the 208 cascading SDK failures.