blaze-host: safe sidecar lifecycle, Blaze switch, build identity

Prerequisites for the live FIFA A/B. Two safeguards here exist because the
corresponding failure actually happened, not because it was imagined.

BUILD IDENTITY. build.rs stamps commit + working-tree cleanliness; the host
prints commit, tree state, profile and a fingerprint of the bundled config
table at startup, into both the log and the trace. A dirty tree prints an
explicit "do NOT treat results from this binary as parity evidence" warning.
The previous step left four sidecars running, two serving mutated builds, and
nothing in their output said so.

SIDECAR LIFECYCLE (sidecar.sh). start/stop/status/check-orphans/with. Start
refuses when any sidecar is already running or the port is busy. Stop kills,
waits, then PROVES it: PID gone AND port free AND no stray processes, failing
if any check does not hold. `with -- CMD` traps EXIT/INT/TERM so cleanup runs
however the command exits.

  Bug found and fixed while testing it: orphan detection used `pgrep -f`,
  which matched any process whose command line merely mentioned the name --
  including the shell running the test script. It now matches the resolved
  executable via /proc/PID/exe. `pgrep -x` is unusable because Linux truncates
  the process name to "openfut-blaze-h".

BLAZE SWITCH (blaze-switch.sh). Redirects Blaze to the sidecar with a scoped
NAT rule instead of editing the frozen Python oracle, whose redirector
advertises a hardcoded BLAZE_PORT = 42130. Rules match only <LAN_IP>:42130;
127.0.0.1:42130 is deliberately left alone so Python stays reachable on
loopback and the A/B compares real Python against real Rust. Verified both
directions live: LAN->Rust with the switch on, LAN->Python with it off.

  Bug found and fixed: `off` reported success while two rules remained active
  and rollback had NOT happened. It matched `--comment "tag"` with quotes this
  iptables does not emit -- and the verification used the SAME broken matcher,
  so it confirmed its own failure. A rollback that lies is worse than one that
  fails. Now matched on the bare tag, verified with iptables-save plus a
  tag-independent check that nothing still redirects the port.

  Second flaw fixed: `sidecar.sh stop` originally warned about a live switch
  and then stopped anyway, creating the exact broken state it warned about. It
  now REFUSES, with --force as the deliberate override.

The general rule this all converges on, now stated in the README: a
verification must not share the failure mode of the thing it verifies.

116 tests still passing; clippy clean; Python backend untouched and contract
suite 446/446. NAT table left clean, no orphan processes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
funman300
2026-08-11 01:54:40 +00:00
parent a9eb54ae9c
commit e091921b18
6 changed files with 587 additions and 16 deletions
+69 -15
View File
@@ -113,25 +113,79 @@ Automated, re-runnable now:
Requiring a FIFA client on the game machine — **not yet done**:
5. ⬜ FIFA reaches FUT with Rust Blaze.
6.Close FIFA completely.
7.FIFA reaches FUT a second time.
8. ⬜ Restore Python Blaze and confirm rollback works.
9. ⬜ Switch back to Rust and confirm again.
10.Only then is Rust Blaze a viable runtime replacement.
6.Open a pack — exercise a known-working FUT action, not just bootstrap.
7.Close FIFA completely.
8. ⬜ Repeat 56 with Rust Blaze.
9. ⬜ Switch back to Python Blaze and verify FUT still works.
10.Switch to Rust once more and verify again.
Gates 8 and 9 matter as much as 5: `Python → Rust → Python → Rust` proves the
rollback path rather than asserting one exists.
Gates 9 and 10 matter as much as 5: `Python → Rust → Rust → Python → Rust`
proves the rollback path rather than asserting one exists.
### Running gate 5
## Process and switch safety
Keep the Python container exactly as it is. On the game machine, redirect **only
the Blaze destination** to the sidecar's port; the redirector, Nucleus, roster,
UTAS and POW keep hitting Python. The single changed variable is then Python
Blaze vs Rust Blaze.
Both were built after real incidents, not speculatively.
The redirector is what tells the client where Blaze lives, so the cleanest
switch is to point the Python redirector's advertised Blaze port at the sidecar
rather than reconfiguring the client.
* **Orphaned sidecars.** A previous session's mutation runs left four sidecars
listening, two serving deliberately broken builds. `sidecar.sh` refuses to
start when any sidecar is already running, and `stop` verifies both that the
PID is gone and that the port is free — failing if either check does not hold.
Orphan detection matches the resolved *executable*, not the command line:
`pgrep -f` was tried first and matched any shell whose arguments merely
mentioned the name.
* **A rollback that lied.** `blaze-switch.sh off` once reported success while
two rules remained active, because it matched `--comment "tag"` with quotes
that this iptables does not emit — and the verification used the same broken
matcher, so it confirmed its own failure. Rules are now matched on the bare
tag string, and `off` verifies with `iptables-save` plus a tag-independent
check that nothing still redirects the port.
The general lesson, now applied throughout: **a verification must not share the
failure mode of the thing it verifies.**
### Running gates 510
The Python redirector advertises a hardcoded `BLAZE_PORT = 42130`
(`blaze_responder_v3b.py:173`), so redirecting Blaze by reconfiguring it would
mean editing the frozen oracle and rebuilding the container. `blaze-switch.sh`
does it with a scoped NAT rule instead: no Python change, instant rollback.
Rules match only `<LAN_IP>:42130`. Traffic to `127.0.0.1:42130` is deliberately
left alone, so Python stays directly reachable on loopback and the A/B keeps
comparing real Python against real Rust.
```bash
cargo build -p openfut-blaze-host
export OPENFUT_ADVERTISE=<LAN_IP> OPENFUT_BIND=0.0.0.0 \
POW_CONTENT_HOST=<LAN_IP>:8085 \
OPENFUT_BLAZE_HOST_BIND=0.0.0.0 OPENFUT_BLAZE_HOST_PORT=<FREE_PORT> \
OPENFUT_BLAZE_TRACE=/tmp/rust-blaze.trace
./sidecar.sh start # refuses if an orphan or the port is busy
./blaze-switch.sh on <LAN_IP> <FREE_PORT> # Blaze -> Rust
./blaze-switch.sh status # confirm before launching FIFA
# … launch FIFA, reach FUT, OPEN A PACK, close FIFA, repeat …
./blaze-switch.sh off # Blaze -> Python (rollback)
./sidecar.sh stop # refuses while the switch is on
```
`sidecar.sh stop` **refuses** while the switch is on: stopping the sidecar then
would leave Blaze pointed at a dead port. Use `stop --force` only deliberately.
Evidence to keep from each live run:
* `/tmp/rust-blaze.trace` — the normalized trace, which begins with the build
banner, so a session is attributable to an exact binary and config table
* the sidecar log — connection accepted, preAuth, login, the three
notifications, subsequent commands, close reason
* whether the pack opened, not just whether the hub loaded
Then compare the Rust trace against a Python session trace. Message numbers and
timestamps are session-dependent and masked; the semantic sequence and payload
shapes must match.
## Diagnostics