From 127234b58cff12e63ede821d781c35d17628f299 Mon Sep 17 00:00:00 2001 From: PJ Date: Sun, 16 Aug 2026 01:20:33 +0530 Subject: [PATCH] docs(runner): say what makes the two reads comparable the reread's comment claimed the round trip was the only interval between them; what it left out is that the two rpcs have to read the same way, which the repo's own android backend did not do. --- internal/runner/foreground_guard_last_action_test.go | 6 ++++-- internal/runner/runner.go | 7 +++++++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/internal/runner/foreground_guard_last_action_test.go b/internal/runner/foreground_guard_last_action_test.go index 6a5a265..426f672 100644 --- a/internal/runner/foreground_guard_last_action_test.go +++ b/internal/runner/foreground_guard_last_action_test.go @@ -74,8 +74,10 @@ func (d *leavesForegroundAfterSubmitDriver) Snapshot(context.Context) (string, d return fmt.Sprintf(homeWithTxnCount, d.committed.Load()), driver.Image{}, nil } -// No device answers Snapshot and Hierarchy off different trees, and the runner -// reads both per step, so this one answers them off the same commit count. +// The runner reads both per step and compares them, so a device that answered +// them off different trees would make every step of this test transitional and +// judged by nothing. The sidecar serves both off one read path (snapshotTree) +// for the same reason; this one answers them off the same commit count. func (d *leavesForegroundAfterSubmitDriver) Hierarchy(context.Context) (string, error) { return fmt.Sprintf(homeWithTxnCount, d.committed.Load()), nil } diff --git a/internal/runner/runner.go b/internal/runner/runner.go index 53fa151..dfde026 100644 --- a/internal/runner/runner.go +++ b/internal/runner/runner.go @@ -1079,6 +1079,13 @@ retryLoop: // filling in. Two reads a read apart are the cheapest thing that can see it // happening: the round trip IS the interval, so there is no sleep here. // +// The comparison only means anything because the Hierarchy RPC serves the tree +// the snapshot's own read produces (see snapshotTree in the sidecar). Off the +// bare device read it does not: with an IME standing open, the snapshot answers +// with 134 nodes and the bare read with 489, and the pair then differs over +// whether the sidecar closed a keyboard between them rather than over anything +// the app did. +// // Waiting for the change to stop was measured on an API 34 device and refused: // a 750ms-quiet poll capped at 2s cost a median 1434ms against 76ms for one // read, hit its cap on every frame it fired for, and still handed back a frame