Summary
The unit test provider::login_relay::tests::device_auth_relay_emits_url_then_code (engine/houston-engine-core/src/provider/login_relay.rs:886) fails non-deterministically — roughly 2 out of 3 runs, even in isolation, and it fails fast (~0.00s, not via the 5s timeout).
Repro
cargo test -p houston-engine-core --lib \
provider::login_relay::tests::device_auth_relay_emits_url_then_code -- --exact
# run it a handful of times -> ~2/3 print: test result: FAILED
Symptom
The panic is the other => arm at line 886 — i.e. the second awaited event (ev2) is not the expected ProviderLoginUrl { user_code: Some("ABCD-EFGHI"), .. }.
The test writes a canned device-auth blob (the https://auth.openai.com/codex/device URL line and the one-time-code line) to the fake CLI's stdout in a single write, then the child exits. The relay is expected to emit ProviderLoginUrl twice: URL-only, then URL+code. When stdout arrives as one chunk and/or the child exits before the code line is processed as a distinct event, ev2 ends up being a different HoustonEvent (e.g. ProviderLoginComplete) -> panic.
Looks like a race on stdout chunking / event ordering over the shared LOGIN_SESSIONS broadcast (the test itself comments on the shared global state it has to clean up).
Pre-existing — not from #483 / #484
Confirmed independent of the provider-resolution work in #484: with all working-tree changes stashed and checked out at the first-fix commit b83fdf4, the test still fails ~2/3 in isolation. #483/#484 never touch provider/login_relay.rs.
Suggested fix direction
Make the relay/test deterministic — e.g. have the fake child emit the URL line, flush/await, then the code line, then block on stdin instead of exiting; or make the test tolerant of event ordering (drain until it has seen the URL+code event rather than asserting it is exactly the 2nd event).
Linear: HOU-421
Summary
The unit test
provider::login_relay::tests::device_auth_relay_emits_url_then_code(engine/houston-engine-core/src/provider/login_relay.rs:886) fails non-deterministically — roughly 2 out of 3 runs, even in isolation, and it fails fast (~0.00s, not via the 5s timeout).Repro
Symptom
The panic is the
other =>arm at line 886 — i.e. the second awaited event (ev2) is not the expectedProviderLoginUrl { user_code: Some("ABCD-EFGHI"), .. }.The test writes a canned device-auth blob (the
https://auth.openai.com/codex/deviceURL line and the one-time-code line) to the fake CLI's stdout in a single write, then the child exits. The relay is expected to emitProviderLoginUrltwice: URL-only, then URL+code. When stdout arrives as one chunk and/or the child exits before the code line is processed as a distinct event,ev2ends up being a differentHoustonEvent(e.g.ProviderLoginComplete) -> panic.Looks like a race on stdout chunking / event ordering over the shared
LOGIN_SESSIONSbroadcast (the test itself comments on the shared global state it has to clean up).Pre-existing — not from #483 / #484
Confirmed independent of the provider-resolution work in #484: with all working-tree changes stashed and checked out at the first-fix commit
b83fdf4, the test still fails ~2/3 in isolation. #483/#484 never touchprovider/login_relay.rs.Suggested fix direction
Make the relay/test deterministic — e.g. have the fake child emit the URL line, flush/await, then the code line, then block on stdin instead of exiting; or make the test tolerant of event ordering (drain until it has seen the URL+code event rather than asserting it is exactly the 2nd event).
Linear: HOU-421