'Rust did not receive it' is weaker than 'Python did'. The redirector always
runs on Python and is never switched, so it advertises the Blaze endpoint on
every run; whether Python then receives the Blaze CONNECT it just advertised
says where the hop actually went.
This is already visible in the existing logs and settles gate 5-6 more firmly
than the sidecar record alone:
02:02:13 Python REDIR SENT -> 10.10.0.120:42130 (to .105)
02:02:13 Rust conn-0005 CONNECT from 10.10.0.105
Python received NO Blaze CONNECT
Same second, both sides: Python advertised the endpoint and did not get the
connection; Rust did. It is also the mechanism gate 8 needs in reverse.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
For the live FIFA gates. Records switch rules, sidecar status, log, trace and
the Python contract result into a timestamped bundle, and reports CONFIGURED
and OBSERVED state as two distinct sections.
The separation is the whole point. 'blaze-switch.sh status = ON' is an
assertion produced by the same tooling that performs the switch, and that
tooling reported a successful rollback once when none had happened. The
observed half comes from an unrelated source: the sidecar's own record of
which peers connected to it. A non-loopback peer in that log proves the
client's Blaze traffic landed on Rust without depending on reading an iptables
rule correctly.
Verified both ways: loopback-only traffic reports 'a FIFA session did NOT land
here'; a non-loopback peer reports that it observably did.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
funman300