The android-ech workflow has been red on main for four consecutive pushes, and the status page's picture of that suite is stale as a result.
What is failing
:android-ech:connectedDebugAndroidTest. The Gradle job summary shows :ech-fixture:runEchFixture succeeding (✅) and :android-ech:connectedDebugAndroidTest failing (❌), so the fixture containers start and the instrumentation step is what dies.
History
The first failure, a6fac14, touched nothing but documentation and the static site. That rules out a code change in that commit as the cause and points at the emulator, the runner image, or something time-dependent rather than at the suite itself.
What the artifact says
The uploaded android-ech-test-results-pinned-snapshot is 1490 bytes and contains no androidTest-results XML at all — only run-metadata.json. So the job died before any test could report a result. That is the case jobStatus in run-metadata.json exists for, and the status page is showing it correctly; there is simply nothing else to show.
Where I got stuck
GitHub's job-log API returns only the post-job cleanup tail for this job however I ask for it — tail_lines up to 260, and failed_only on the run — so I never saw the actual error. Diagnosing this needs the raw log downloaded from the web UI, or a workflow_dispatch re-run with more logging.
Candidates worth checking first
- The emulator failing to boot or
adb losing the device — the run does terminate an orphan adb process during cleanup.
- The API 37 system image moving, or
ANDROID_AVD_HOME / snapshot caching changing under the runner.
adb reverse not being set up in time, which would make every test fail rather than the job die — less likely given no XML at all.- Something in the ECH fixture's published ports file arriving late, since
run-ech-test.sh couples the fixture and the instrumentation run.
Why it matters
The daily run is the point of this repository, and one of the three workflows has not produced a usable result in four pushes. It is also the suite with no independent coverage: network's EchTest reports on the public ECH servers, and android-ech is the only thing asserting the client behaviour against a fixture nobody else can change.
Resolved
Green on main since a320bc1, and green for every run since:
I can't attribute the fix to one commit without bisecting, and it isn't worth doing now. The plausible candidates all landed in the same window: the emulator-readiness change (#31), giving OkHttp the application context before the suites run (#37), and a run of toolchain bumps — AGP to 9.3.1 (#45), Gradle to 9.7.0 (#48), Kotlin to 2.4.10 (#46) — any of which could plausibly have moved an instrumentation run that was dying before it could report.
Closing as fixed. If it returns, the useful thing this issue leaves behind is the diagnostic dead end: the job-log API truncates before the error, so the raw log from the web UI is the way in.
The
android-echworkflow has been red onmainfor four consecutive pushes, and the status page's picture of that suite is stale as a result.What is failing
:android-ech:connectedDebugAndroidTest. The Gradle job summary shows:ech-fixture:runEchFixturesucceeding (✅) and:android-ech:connectedDebugAndroidTestfailing (❌), so the fixture containers start and the instrumentation step is what dies.History
README.mdandsite/**only (#23)networksuite (#2)pages.ymlenablement (#25)The first failure, a6fac14, touched nothing but documentation and the static site. That rules out a code change in that commit as the cause and points at the emulator, the runner image, or something time-dependent rather than at the suite itself.
What the artifact says
The uploaded
android-ech-test-results-pinned-snapshotis 1490 bytes and contains noandroidTest-resultsXML at all — onlyrun-metadata.json. So the job died before any test could report a result. That is the casejobStatusinrun-metadata.jsonexists for, and the status page is showing it correctly; there is simply nothing else to show.Where I got stuck
GitHub's job-log API returns only the post-job cleanup tail for this job however I ask for it —
tail_linesup to 260, andfailed_onlyon the run — so I never saw the actual error. Diagnosing this needs the raw log downloaded from the web UI, or aworkflow_dispatchre-run with more logging.Candidates worth checking first
adblosing the device — the run does terminate an orphanadbprocess during cleanup.ANDROID_AVD_HOME/ snapshot caching changing under the runner.adb reversenot being set up in time, which would make every test fail rather than the job die — less likely given no XML at all.run-ech-test.shcouples the fixture and the instrumentation run.Why it matters
The daily run is the point of this repository, and one of the three workflows has not produced a usable result in four pushes. It is also the suite with no independent coverage:
network'sEchTestreports on the public ECH servers, andandroid-echis the only thing asserting the client behaviour against a fixture nobody else can change.Resolved
Green on
mainsince a320bc1, and green for every run since:I can't attribute the fix to one commit without bisecting, and it isn't worth doing now. The plausible candidates all landed in the same window: the emulator-readiness change (#31), giving OkHttp the application context before the suites run (#37), and a run of toolchain bumps — AGP to 9.3.1 (#45), Gradle to 9.7.0 (#48), Kotlin to 2.4.10 (#46) — any of which could plausibly have moved an instrumentation run that was dying before it could report.
Closing as fixed. If it returns, the useful thing this issue leaves behind is the diagnostic dead end: the job-log API truncates before the error, so the raw log from the web UI is the way in.