fix(cloud): cancel a screen read that its caller gave up on - #2516
Conversation
thymikee
changed the title
|
Size Report
Startup median (7 runs, lower is better):
|
|
The cancellation wiring is sound at 1adbc57, but the new recovery advice cannot work: webdriver-interactor.ts:611-614 and the AWS docs suggest a larger --timeout for webdriver_request_timeout, while that flag only widens the daemon envelope. The source request still uses the transport policy timeout (30 seconds by default), with no timeout override from snapshot. Remove that advice or connect it to an actual source-read budget. Current checks pass and there are no conflicts; the reported AWS run covers ordinary reads, not cancellation and recovery on the provider. |
63ef151 to
c740e5c
Compare
|
Fixed in The hint now names whose budget it is and drops the advice, the AWS docs say the same, and two added |
c652fd1 to
2d7d741
Compare
|
The timeout advice is corrected on 2d7d741. One documentation issue remains in website/docs/docs/snapshots.md:63: cancelling the client read does not establish that later provider commands stop waiting behind the abandoned capture. The Appium tree walk can continue, as the PR description acknowledges. Please bound that paragraph to stopping client-side waiting and acknowledge that provider work may continue. The aborting fixture proves local cleanup, not provider queue recovery. Current checks pass and there are no conflicts. |
A hosted page-source read that outran its request was dropped by the client while the driver kept walking the UI tree. Nothing at the wire said the answer was no longer wanted, so the read stayed in flight and held the session it was blocking. On a screen that never goes still -- a looping video, a live ticker, continuous animation -- every later command then queued behind a capture nobody was waiting for, which is what makes one stuck `snapshot -i` look like a frozen session. Bind the read to the request that asked for it, on both Android and iOS, and say what a source read that runs out of budget was waiting for. The timeout keeps its `webdriver_request_timeout` reason and gains a hint naming a screen that never goes still, so the rented minutes end with a cause rather than a silent hang. Closes #2509
The hint and the AWS docs both told the caller to retry with a larger `--timeout`. That flag widens the command envelope around the read; the read's own budget is the transport's, so the advice could not work and cost rented minutes to discover. The report on #2509 shows exactly that experiment failing at 65 seconds. Say whose budget it is, and offer the two things that do work: a `screenshot`, which never reads the tree, and the `@refs` an earlier snapshot captured.
The scenario comment credited this layer with the lease-gone symptom, which a ten-minute cloud WebDriver lease rules out for the reported run. And one assertion message said the driver's own tree walk had been cancelled, when what the test observes is our request being hung up at the wire. Behaviour and coverage are unchanged; the test now says what it measures.
…lives The read that fails is shared hosted WebDriver behaviour, so it belongs on the Snapshots page rather than only under one provider. The provider page keeps the part that is about being metered. Both pages name the two dead ends, since both were tried on the reported run: a larger `--timeout`, which widens the command around the read, and `settings animations`, which hosted WebDriver sessions do not implement.
Hanging up the client read proves agent-device stops waiting and stops holding the session. It says nothing about the provider, whose tree walk can keep running and can still occupy that session's queue server-side. The paragraph claimed the recovery the fixture does not prove.
2d7d741 to
513df98
Compare
|
Bound in Stack was also rebased onto |
|
The cancellation wording is now accurate on 513df98: client waiting stops, while the provider walk may continue and occupy its queue. No actionable findings remain. The runtime changes are preserved by the rebase and the reported live AWS evidence still applies; current CI is running, so merge readiness awaits those checks. |
thymikee
added
the
ready-for-human
1 participant
Summary
A hosted page-source read that outran its request was dropped by the client while the driver kept
walking the UI tree. Nothing at the wire said the answer was no longer wanted, so the read stayed in
flight and the session stayed busy serving a capture nobody was waiting for. On a screen that never
goes still — looping video, live ticker, continuous animation — that is what turns one stuck
snapshot -iinto a frozen session.The read is now bound to the request that asked for it, on Android and iOS, and a source read that
runs out of budget keeps its
webdriver_request_timeoutreason and names the cause.agent-device snapshot -i --session df # reason webdriver_request_timeout; the hint names a never-idle screen and says --timeout cannot widen this readCloses #2509. Touched files: 10. The lease half of the investigation is stacked separately in #2517.
Validation
pnpm check:affected --runpassed at513df9839(all runnable checks; provider integration andcoverage are CI-owned jobs on this head).
npx vitest run packages/provider-webdriver/src test/integration/provider-scenarios/cloud-webdriver-runtime.test.ts— green. Red without the fix:
the abandoned capture was still running after its client hung up.connect aws-device-farm,snapshot -i(66.4s cold, 25 nodes),
screenshot(6.3s, 1080x2400), warmsnapshot -i(0.37s). Session closedand disconnected.
--timeoutis gone from the hint and the docs. It widens the command around the read,not the read itself — which is why the report's 65-second attempt changed nothing. A real source-read
budget is unimplemented and deserves its own issue.
WebDriver behaviour belongs; the provider page keeps the metered-device part.
lease not activeis a distinct mechanism and is not fixed here.