mirror of
https://github.com/okieselbach/AutopilotMonitor.git
synced 2026-10-24 12:42:38 +00:00
Oliver Kieselbach
3aa8b95676
Round-four review, confirmed — and the cause sits a layer below where I had been fixing. The IsBackfill return added last round only guarded the coordinator's own completion logic. Upstream of it, ShellCoreTracker still raised FinalizingSetupPhaseTriggered, the coordinator still forwarded EspExited to the adapter before that return, and the adapter discards the args entirely (OnEspExited(...) => EmitEspExiting()). So a replayed exit still arrived at the reducer as an ordinary, unmarked EspExiting. There it is decisive: HandleEspExitingV1 passes espFinalExitInFlight: true for every arriving exit, and IsPostAccountSetupFinalExit orders exits by ingest ordinal rather than timestamp — so a historic exit replayed today reads as post-AccountSetup by construction. With state restored from the snapshot (AccountSetup entered, a genuine IME user session, desktop arrived) arm C of ShouldTransitionToAwaitingHello opens on the Device→Account handoff. The reducer is itself a completion gate and cannot tell the two apart, so the fix has to be upstream. The replay is therefore narrowed to what is provably safe: the Hello-wizard start (62404). That fact is conservative — it vetoes a premature "Hello is disabled" skip and can never by itself complete a session, so replaying it can only make the agent wait longer. It is also the observation session 772fe502 wrote the replay for. A 62407 is no longer raised at all, neither exit nor failure: the exit because Windows writes the identical description for the intermediate and the final one and nothing downstream can order it, the failure because re-injecting it as fresh can fail a session that recovered on retry (ANALYZE-ESP-006). Skipped records are reported once as an agent_trace with counts and bounds — silently dropping evidence is how this class of bug survives. The cross-layer proof is now a pair, as the review asked: ClassicEspExitingOnRestoredStateTests pins that the reducer opens on any arriving exit (including one with an hour-old source timestamp), and ShellCoreTrackerReplayScopeTests pins that the replay never produces one. Dead machinery removed with it: EspExitedEventArgs.IsBackfill, allowEspExit, the newest-exit selection, the IsBackfill return. The method is now called BackfillRecentHelloWizardStart. One pre-existing integration test drove EspExited through HandleBackfillRecord because the replay is easier to call than the event-log watcher, and its class doc claimed that was the production path — it never was, the replay had no caller when that test was written. Switched to the live path and the doc corrected. Agent V2.Core 2361, DecisionCore 538, Backend 4287, all green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>