Repository navigation
Android smoke: first fixture capture stalls before any readable snapshot #3831
Copy link
Copy link
Closed
Labels
bugSomething isn't workingSomething isn't working
Description
Android smoke intermittently fails before its first readable capture after opening the fixture. Diagnose and fix the capture/setup boundary without increasing the wait deadline or adding retry-only recovery.
Observed command:
agent-device wait text "Automation lab" 10000 --platform android --serial emulator-5554 --session <session> --daemon-server-mode dual --jsonEvidence:
- PR test(ios): speed up fixtures and run native regressions nightly #3824,
14f32fb218ac9e5608012bf6a5805652dc61f7fc: run 39287002936.smoke-android-emulator.test.ts:7:1, scenariosmoke:automation-system,COMMAND_FAILED, reasonwait_capture_stalled, one capture, zero readable captures, deadline after 10439ms. - Earlier main,
a61556b8fd3268dd0b8032409ad0f0d06107019b: run 39025922562. Same command, scenario, assertion and reason; one capture, zero readable captures, 10232ms poll. - Both runs retain
android-artifacts. Current failure screenshot shows Automation lab; the subsequent diagnostic snapshot succeeds with healthy android-helper capture (619ms helper / 1914ms snapshot). No crash appears in its crash buffer. - PR test(ios): speed up fixtures and run native regressions nightly #3824 leaves Android runtime, integration scenarios, Android workflow/setup, package manifest and lockfile unchanged from its base
a661e43d83735fc74a02118b5698e5d45e03ee21. That exact base's Android run passed. This is evidence of an intermittent pre-existing signature, not proof of infrastructure or a complete root cause. - Correction: the request NDJSON and daemon log are present under the artifact hidden
.agent-devicedirectory. The first scan omitted hidden files. The request shows 2314ms helper install, then 5162ms persistent-session capture including a UiAutomation connection timeout, followed by 2958ms one-shot fallback cancelled at the wait deadline. A different branch's run 39221668804 reportswait_target_absentwith a system overlay; do not conflate it with this zero-readable-capture failure.
Required behavior and completion:
- Retain the failed first-capture phase timings and cancellation/setup evidence in CI artifacts.
- Build a cold-open reproduction on an isolated Android emulator and compare unchanged base/head with the same command and no competing tests.
- Identify the owning capture/setup defect and prove the fix with a regression at that boundary and hosted Android smoke.
- Keep deadline/cancellation and failure exits intact. A later successful snapshot alone does not prove infrastructure contention.
Blocks Android validation of #3824. Other lanes and local validation do not replace this obligation.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working
Activity
thymikee commentedon Oct 19, 2026
Decision: scope: fix the CI preparation boundary in an independent PR. The recovered request trace shows helper installation (2314ms), a persistent UiAutomation connection failure (5162ms including startup/retirement), then one-shot fallback cancelled at the 10-second landmark wait deadline. Add a required helper-backed snapshot preflight before each scenario landmark wait. Keep the original wait deadline and propagate failed preflights. This isolates first-use preparation from app-observation assertions; it does not claim to repair Android framework UiAutomation initialization itself. Current local smoke passes all seven scenario groups in 73.1s. Cold-setup injection and negative controls are in progress.