JMR-dev/LibreMediaConverter
1
0
Fork 0
Code Issues 16 Pull Requests Actions Packages Projects Releases Wiki Activity

The e2e report says a wedged leg completed cleanly #118

New Issue
Closed
opened 2026-08-26 02:35:03 +00:00 by JMR-dev · 2 comments
JMR-dev commented 2026-08-26 02:35:03 +00:00 (Migrated from github.com)
Copy Link
Copy Source

The report added by #111 prints completed cleanly: yes for a leg that the wedge
timeout had just killed. Observed on PR #115 (a docs-only change), run
32922652540, E2E API 34, job 98035980326:

02:30:07   expected:          59
02:30:07   received:          59
02:30:07   failed:            unknown
02:30:07   completed cleanly: yes
02:30:09 ERROR        | bad color buffer handle 375
02:30:13 ##[warning]E2E api34 WEDGED (api34) -- see the wedge-diagnostics-api34 artifact

The report runs as part of the wedge path — six seconds before the warning — and
answers a question it was not asked. completed cleanly means "instrumentation
was not aborted", which was true; the leg still died, killed by WEDGE_TIMEOUT
after ~22 minutes. A reader scanning the table sees received: 59 and
completed cleanly: yes and has to notice a separate ##[warning] line to learn
the leg failed at all.

failed: unknown is the honest half and is doing its job: gradle never printed a
summary line, so the count genuinely is not knowable. That part should stay.

What happened underneath, for whoever picks this up: the run reached
52/59 completed. (2 skipped) (0 failed), the XML ultimately carried all 59, and
then the leg hung — a post-test hang during teardown rather than an abort or an
assertion failure. bad color buffer handle 375 is the emulator's own complaint
two seconds later. That is a new mode relative to the three on #102, and the
only reason it is legible at all is the #111 report; before it, this was an
anonymous red leg.

Suggested shape: when the wedge path is what invoked the report, say so in
the table rather than leaving completed cleanly to answer for it — e.g. a
wedged: yes (killed after Ns) row, or suppressing completed cleanly in favour
of the wedge line. Do not change failed: unknown, and nothing here should
change the pass/fail rules or any job's status — the leg already fails
correctly. This is about what the table says, not what it decides.

Test: e2e-report-shape.sh is exercised against captured CI output rather
than a live emulator (that is how #111 was verified, and this host cannot run API
37 at all). The captured stdout of job 98035980326 is a ready-made fixture for
the wedge case.

The report added by #111 prints `completed cleanly: yes` for a leg that the wedge timeout had just killed. Observed on PR #115 (a **docs-only** change), run `32922652540`, `E2E API 34`, job `98035980326`: ``` 02:30:07 expected: 59 02:30:07 received: 59 02:30:07 failed: unknown 02:30:07 completed cleanly: yes 02:30:09 ERROR | bad color buffer handle 375 02:30:13 ##[warning]E2E api34 WEDGED (api34) -- see the wedge-diagnostics-api34 artifact ``` The report runs as part of the wedge path — six seconds before the warning — and answers a question it was not asked. `completed cleanly` means "instrumentation was not aborted", which was true; the leg still died, killed by `WEDGE_TIMEOUT` after ~22 minutes. A reader scanning the table sees `received: 59` and `completed cleanly: yes` and has to notice a separate `##[warning]` line to learn the leg failed at all. `failed: unknown` is the honest half and is doing its job: gradle never printed a summary line, so the count genuinely is not knowable. That part should stay. **What happened underneath**, for whoever picks this up: the run reached `52/59 completed. (2 skipped) (0 failed)`, the XML ultimately carried all 59, and then the leg hung — a post-test hang during teardown rather than an abort or an assertion failure. `bad color buffer handle 375` is the emulator's own complaint two seconds later. That is a **new mode** relative to the three on #102, and the only reason it is legible at all is the #111 report; before it, this was an anonymous red leg. **Suggested shape:** when the wedge path is what invoked the report, say so in the table rather than leaving `completed cleanly` to answer for it — e.g. a `wedged: yes (killed after Ns)` row, or suppressing `completed cleanly` in favour of the wedge line. Do not change `failed: unknown`, and **nothing here should change the pass/fail rules or any job's status** — the leg already fails correctly. This is about what the table says, not what it decides. **Test:** `e2e-report-shape.sh` is exercised against captured CI output rather than a live emulator (that is how #111 was verified, and this host cannot run API 37 at all). The captured stdout of job `98035980326` is a ready-made fixture for the wedge case.
JMR-dev commented 2026-08-26 03:24:31 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Second sighting, different API level — the mode is not specific to 34

2026-08-26T03:23Z, run on PR #117, E2E API 33, job 98045364829:

  expected: 60   received: 60   failed: unknown   completed cleanly: yes
##[warning]E2E api33 WEDGED (api33) -- see the wedge-diagnostics-api33 artifact

Same shape as the API 34 sighting that prompted this ticket: every test ran (received equals
expected), gradle never printed a summary, and the leg then hung in teardown until WEDGE_TIMEOUT
killed it. No abort trace this time — hasReadColorBufferDma and TaskSnapshotPer are both absent,
so this is not #108 wearing a different hat.

Two things this settles:

  • It is not an API-34 quirk. 34 and now 33.
  • The misreport reproduces exactly. completed cleanly: yes again, printed on a leg the wedge
    had just killed — which is what this ticket is about, and #121 is fixing.

Worth noting for whoever reviews #121: both known samples have received == expected and
failed: unknown. That combination — a full test count with an unknowable failure count — may be a
usable signal in its own right, but do not infer the wedge from it. #121 was briefed to take the
wedge signal explicitly from e2e-run.sh rather than guess it from log shape, and that is still the
right call; this is a corroborating pattern, not a substitute.

## Second sighting, different API level — the mode is not specific to 34 `2026-08-26T03:23Z`, run on PR #117, **E2E API 33**, job `98045364829`: ``` expected: 60 received: 60 failed: unknown completed cleanly: yes ##[warning]E2E api33 WEDGED (api33) -- see the wedge-diagnostics-api33 artifact ``` Same shape as the API 34 sighting that prompted this ticket: **every test ran** (`received` equals `expected`), gradle never printed a summary, and the leg then hung in teardown until `WEDGE_TIMEOUT` killed it. No abort trace this time — `hasReadColorBufferDma` and `TaskSnapshotPer` are both absent, so this is not #108 wearing a different hat. Two things this settles: - **It is not an API-34 quirk.** 34 and now 33. - **The misreport reproduces exactly.** `completed cleanly: yes` again, printed on a leg the wedge had just killed — which is what this ticket is about, and #121 is fixing. Worth noting for whoever reviews #121: both known samples have `received == expected` and `failed: unknown`. That combination — a full test count with an unknowable failure count — may be a usable signal in its own right, but **do not infer the wedge from it**. #121 was briefed to take the wedge signal explicitly from `e2e-run.sh` rather than guess it from log shape, and that is still the right call; this is a corroborating pattern, not a substitute.
JMR-dev commented 2026-08-26 03:27:16 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Correcting myself, and a much stronger case for this ticket

I read the wedge diagnostics artifacts — which I had said were worth reading and nobody had — and
my description of this mode was wrong in both earlier comments.

I wrote that "every test ran, then the leg hung in teardown", on the strength of received: 60
matching expected: 60. That is not what happened. In both recorded wedges the TestRunner log ends
on a started: with no finished::

API 34, run 32921547861:  02:13:50.515 started: thePickedInputSurvivesARealRotation(SafPickerRoundTripTest)
API 33, run 32924766720:  03:07:07.917 started: thePickedInputSurvivesARealRotation(SafPickerRoundTripTest)

grep -c "finished: thePickedInputSurvivesARealRotation" is 0 in both. A test was still running
when the timeout fired. Filed as #122.

What that means for this ticket

The misreport is worse than "completed cleanly answers the wrong question". On a wedged leg the
table also asserts received: 60 — a count that includes a test which never returned. So the two
rows a reader is most likely to trust are both wrong in the same direction, and together they say
"all 60 tests came back and nothing was aborted" about a leg that died with a test still executing.

failed: unknown remains the only honest row.

The most valuable thing the wedge report could say

The diagnostics artifact already contains the answer — --- running/last instrumented test (logcat TestRunner) --- is literally the first section — but you have to download and unzip an artifact to
see it, and only after noticing the ##[warning] line at all.

Naming the last test started with no matching finished: would turn a 20-minute anonymous red
into a one-line diagnosis, exactly as #111 did for ordinary failures. That is how #122 was found,
and it took a manual artifact download to do it.

I am not silently widening #121's scope — it was briefed narrowly and is nearly done. Whether that
belongs in #121 or in a follow-up is a judgement call; if it does not land there, it should be its
own ticket rather than lost in this thread.

Also worth fixing while in here: received should not claim a test came back when the runner never
said finished: for it.

## Correcting myself, and a much stronger case for this ticket I read the wedge diagnostics artifacts — which I had said were worth reading and nobody had — and **my description of this mode was wrong in both earlier comments.** I wrote that "every test ran, then the leg hung in teardown", on the strength of `received: 60` matching `expected: 60`. That is not what happened. In both recorded wedges the TestRunner log ends on a `started:` with no `finished:`: ``` API 34, run 32921547861: 02:13:50.515 started: thePickedInputSurvivesARealRotation(SafPickerRoundTripTest) API 33, run 32924766720: 03:07:07.917 started: thePickedInputSurvivesARealRotation(SafPickerRoundTripTest) ``` `grep -c "finished: thePickedInputSurvivesARealRotation"` is **0** in both. A test was still running when the timeout fired. Filed as **#122**. ## What that means for this ticket The misreport is worse than "`completed cleanly` answers the wrong question". On a wedged leg the table also asserts **`received: 60`** — a count that includes a test which never returned. So the two rows a reader is most likely to trust are both wrong in the same direction, and together they say "all 60 tests came back and nothing was aborted" about a leg that died with a test still executing. `failed: unknown` remains the only honest row. ## The most valuable thing the wedge report could say The diagnostics artifact already contains the answer — `--- running/last instrumented test (logcat TestRunner) ---` is literally the first section — but you have to download and unzip an artifact to see it, and only after noticing the `##[warning]` line at all. **Naming the last test started with no matching `finished:` would turn a 20-minute anonymous red into a one-line diagnosis**, exactly as #111 did for ordinary failures. That is how #122 was found, and it took a manual artifact download to do it. I am not silently widening #121's scope — it was briefed narrowly and is nearly done. Whether that belongs in #121 or in a follow-up is a judgement call; if it does not land there, it should be its own ticket rather than lost in this thread. Also worth fixing while in here: `received` should not claim a test came back when the runner never said `finished:` for it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
above-cut
Worked autonomously overnight: local, JVM-verifiable, no product decision
 accessibility
Barrier affecting people with disabilities
 backlog
Held for manual review: product/UX call, CI/workflow, hardware, or unverifiable here
 bug
Something isn't working
 confirmed
Reviewer demonstrated the defect
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 plausible
Reviewer could not fully demonstrate it; treat as unproven
 question
Further information is requested
 sev:high
High severity
 sev:low
Low severity
 sev:medium
Medium severity
 wontfix
This will not be worked on
No labels bug confirmed sev:low
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
JMR-dev
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: JMR-dev/LibreMediaConverter#118