feat(wait): carry a per-poll timeline in timeout failures - #2344
Open
thymikee wants to merge 1 commit into
Open
Conversation
A wait timeout said `reason`, `readableCaptures`, and `waitedMs`, so a failure could not say where its budget went: the runs behind #2343 spent a 10s budget on one poll (5.8s runner findText on a fresh app, 3.4s of target discovery, a fallback cancelled at the deadline) and reported the same `wait_capture_stalled` as a dead runner. The failure details now carry `captures` and `polls[]`, one entry per poll with `startedMs` on the wait's own clock, `durationMs`, and a typed outcome (readable, unreadable, deadline, runner-restart), next to the unchanged reason and the request-log link. Long waits keep the first five and last twenty-five polls so the response stays compact.
|
Size Report
Startup median (7 runs, lower is better):
|
Member
Author
|
The diagnostic change looks sound at 96e1a80, with one wording correction: not every wait timeout carries the timeline. wait --stable uses a separate error builder, and never-readable strict absence preserves its predicate failure. Please narrow the docs, changelog and PR description to the polling timeout paths that actually emit these fields; no need to expand the implementation here. Android CI failed waiting for Alert result: cancelled. Its output does demonstrate the new timeline: 17 polls, 16 readable, then a deadline at 10,261 ms. That does not establish a regression from this change, but the failed lane still needs resolution before merge. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Diagnostics only; no timeout semantics change. Follow-up 4 from the review of #2331, prerequisite for #2343.
A
waittimeout carriedreason,readableCaptures, andwaitedMs, which cannot say where the budget went. The runs behind #2343 spent a 10s budget on a single poll (5.8s runnerfindTexton a fresh app, 3.4s of target discovery, a fallback cancelled at the deadline) and reported the samewait_capture_stalledas a dead runner would.Change
error.detailson every wait timeout now also carries:captures: every poll attempted, readable or not.polls[]: one entry per poll withstartedMson the wait's own clock,durationMs, and a typedoutcome:readable,unreadable(content verdict the wait rode out),deadline(the deadline cancelled the capture in flight), orrunner-restart(that cancellation carried restart evidence).The top-level
reasonand the existing fields are unchanged;logPathstill links the full request log. Long waits keep the first five and last twenty-five polls so the response stays compact. Whether a readable poll matched is the caller's verdict and is not recorded.Example of the #2343 failure with this change:
Validation
website/docs/docs/commands.mdwait-failure bullet; CHANGELOG entry.