Pitfall Persistence dakka

Rusty Dakka Release Binary Drift

pitfalldakkabuild-systemtesting

What Happened

On 2026-04-23, while bringing up Playwright E2E specs for the Mork dashboard (see [experiments/dakka/2026-04-23-playwright-e2e-specs](/experiments/dakka/2026-04-23-playwright-e2e-specs)), four MQI-related tests (M1, M3, M4, D2) failed against a server that had been “running fine for weeks.” The handler source at crates/server/src/server.rs::mqi_session_handler returned {"mqi":null} with HTTP 200 whenever the DB lookup found nothing: but curl against the running server showed HTTP 404 with an empty body.

$ ls -lt target/release/rusty-dakka target/debug/rusty-dakka crates/server/src/server.rs
-rw-r--r-- ... Apr 23 14:27 crates/server/src/server.rs
-rwxr-xr-x ... Apr 23 14:29 target/debug/rusty-dakka
-rwxr-xr-x ... Apr 17 10:03 target/release/rusty-dakka   ← 6 days stale

The live server was the release binary from 2026-04-17, which predated the Task 6 MQI endpoint fix. Task 8: Verify MQI fix (server restart + browser check) had returned {"mqi":null}: but that was against a dev build, not against the release binary the agent had kept running in the background. Specs written to the new contract failed against the old contract.

Root Cause

cargo run and cargo test rebuild the debug binary on every invocation. target/release/rusty-dakka only rebuilds on an explicit cargo build --release. When iteration happens through cargo run / cargo test cycles, the release binary gets left behind with no feedback signal.

This is a general Rust-binary-staleness hazard, not a dakka bug. It shows up in dakka specifically because the dev workflow is “kill the server, restart with ./target/release/rusty-dakka spawn --port 7331 because it starts faster than cargo run”: which silently pins you to whatever release binary is on disk.

Fix

Before relying on a running dakka server for anything downstream (E2E specs, manual verification, product bug repro), diff the source mtime against the release binary mtime:

ls -lt target/release/rusty-dakka target/debug/rusty-dakka crates/server/src/server.rs

If the release binary is older than any .rs file under crates/server/src/ that touches the handler you are testing, either:

  1. Rebuild: cargo build --release -p rusty-dakka-app (slow, but restores parity).
  2. Run the debug binary instead: ./target/debug/rusty-dakka spawn --port 7331 > /tmp/dakka-server.log 2>&1 & (fast, always current after the last cargo test / cargo run).

Always background the server: cargo run -p rusty-dakka-app: spawn blocks the caller, which kills agent sessions when the caller is Claude Code.

  • [experiments/dakka/2026-04-23-playwright-e2e-specs](/experiments/dakka/2026-04-23-playwright-e2e-specs): the session that surfaced this.
  • [topics/pitfalls/electron-stale-bundle-version-drift](/topics/pitfalls/electron-stale-bundle-version-drift): same class of pitfall on the jobs-apply Electron side.