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

LauncherWiringTest's file-card assertion flaked once on CI in its first day #220

New Issue
Closed
opened 2026-09-06 01:36:11 +00:00 by JMR-dev · 1 comment
JMR-dev commented 2026-09-06 01:36:11 +00:00 (Migrated from github.com)
Copy Link
Copy Source

LauncherWiringTest > a picked document is loaded as input rather than saved to failed once on CI,
in the wave-4 merge train, and passed everywhere else. Filing it rather than shrugging because it is
a new test — added in #214 (ticket #200) on 2026-09-05 — and a test that flakes in its first day
is a defect in the test, not a curiosity.

The occurrence

PR #218, run 34001741668, Unit tests leg:

LauncherWiringTest > a picked document is loaded as input rather than saved to FAILED
    java.lang.AssertionError at LauncherWiringTest.kt:88
628 tests completed, 1 failed

Line 88 is the whole point of the test:

composeRule.onNodeWithTag(TestTags.Converter.FILE_CARD_NAME).assertIsDisplayed()

So the picked URI did not produce a file card within the rule's idle wait.

What it is not

It was initially suspected of being an interaction with #218, which substitutes the Application for
the whole JVM suite (TestLibreMediaConverterApp, #159). That is ruled out: #219 is stacked on
#218, so its CI run contains the same Application change and this test, and its Unit tests leg is
green — 12/12, no failures. Verified with git merge-base --is-ancestor, not assumed from the branch
name.

run contains #218's change Unit tests
#214, #215, #216, #217 no SUCCESS
#218 yes FAILURE
#219 yes SUCCESS

Locally, on a branch carrying everything: the class alone passed 5/5, and the full suite passed 2/2.
So it is one occurrence in six CI runs that contain the test, and it does not reproduce on demand.

Where to look first

The test drives a real ConversionViewModel inside a composition, and the file card appears only
once the screen reaches Ready. Two candidates, both about state the test shares rather than owns:

  • installTestWorkManager(app, Data.EMPTY). A Data.EMPTY output makes a SUCCEEDED job map to
    Failed rather than Converted — this bit #202 during the same wave and cost a timed-out
    awaitState there. If anything leaves a job visible to jobSnapshots, observe() can move the
    screen off Ready and the card never renders.
  • ConversionDependencies.probe is process-global, set in setUp and cleared in tearDown. Any
    path that skips tearDown leaves the next class composing against a real probe.

Neither is confirmed. The useful next step is to run the class after the classes that precede it in
the CI ordering, rather than alone.

Not proposed

A retry rule or an increased timeout. The assertion is the test's only claim; making it wait longer
would hide the case where the wiring genuinely does not fire, which is the transposition defect
#200 exists to catch.

`LauncherWiringTest > a picked document is loaded as input rather than saved to` failed once on CI, in the wave-4 merge train, and passed everywhere else. Filing it rather than shrugging because it is a **new test — added in #214 (ticket #200) on 2026-09-05** — and a test that flakes in its first day is a defect in the test, not a curiosity. ## The occurrence PR #218, run `34001741668`, Unit tests leg: ``` LauncherWiringTest > a picked document is loaded as input rather than saved to FAILED java.lang.AssertionError at LauncherWiringTest.kt:88 628 tests completed, 1 failed ``` Line 88 is the whole point of the test: ```kotlin composeRule.onNodeWithTag(TestTags.Converter.FILE_CARD_NAME).assertIsDisplayed() ``` So the picked URI did not produce a file card within the rule's idle wait. ## What it is not It was initially suspected of being an interaction with #218, which substitutes the `Application` for the whole JVM suite (`TestLibreMediaConverterApp`, #159). **That is ruled out**: #219 is stacked on #218, so its CI run contains the same Application change *and* this test, and its Unit tests leg is green — 12/12, no failures. Verified with `git merge-base --is-ancestor`, not assumed from the branch name. | run | contains #218's change | Unit tests | |---|---|---| | #214, #215, #216, #217 | no | SUCCESS | | #218 | yes | **FAILURE** | | #219 | yes | SUCCESS | Locally, on a branch carrying everything: the class alone passed 5/5, and the full suite passed 2/2. So it is one occurrence in six CI runs that contain the test, and it does not reproduce on demand. ## Where to look first The test drives a **real** `ConversionViewModel` inside a composition, and the file card appears only once the screen reaches `Ready`. Two candidates, both about state the test shares rather than owns: - **`installTestWorkManager(app, Data.EMPTY)`.** A `Data.EMPTY` output makes a SUCCEEDED job map to `Failed` rather than `Converted` — this bit #202 during the same wave and cost a timed-out `awaitState` there. If anything leaves a job visible to `jobSnapshots`, `observe()` can move the screen off `Ready` and the card never renders. - **`ConversionDependencies.probe`** is process-global, set in `setUp` and cleared in `tearDown`. Any path that skips `tearDown` leaves the next class composing against a real probe. Neither is confirmed. The useful next step is to run the class after the classes that precede it in the CI ordering, rather than alone. ## Not proposed A retry rule or an increased timeout. The assertion is the test's only claim; making it wait longer would hide the case where the wiring genuinely does not fire, which is the transposition defect #200 exists to catch.
JMR-dev commented 2026-09-06 04:29:09 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Two more sightings today, both on PRs whose diff cannot reach it — so the "flaked once in its first day" framing in the title is now understating it.

run PR diff shape
34009201110 #232 two androidTest files + one doc LauncherWiringTest failed and #125's deadlock hit the watchdog
34011267951 #235 one new androidTest file 628 tests completed, 1 failed — LauncherWiringTest alone, in 1m07s

Both times the failing assertion is the same one the title names:

LauncherWiringTest > a picked document is loaded as input rather than saved to FAILED

Both passed on re-run with no change.

Worth recording because the second one isolates it. The #232 run also carried #125's Room/WorkManager deadlock, so that failure could be argued as fallout from a run already in trouble. The #235 run had no deadlock, took 1m07s, and failed only this — so this is its own flake and not a symptom of the hang.

Neither PR touches app/src/main or app/src/test. Three sightings now, all on diffs that cannot explain them.

Two more sightings today, both on PRs whose diff cannot reach it — so the "flaked once in its first day" framing in the title is now understating it. | run | PR | diff | shape | |---|---|---|---| | [`34009201110`](https://github.com/JMR-dev/LibreMediaConverter/actions/runs/34009201110) | #232 | two `androidTest` files + one doc | `LauncherWiringTest` failed **and** #125's deadlock hit the watchdog | | [`34011267951`](https://github.com/JMR-dev/LibreMediaConverter/actions/runs/34011267951) | #235 | one new `androidTest` file | `628 tests completed, 1 failed` — `LauncherWiringTest` alone, in 1m07s | Both times the failing assertion is the same one the title names: ``` LauncherWiringTest > a picked document is loaded as input rather than saved to FAILED ``` Both passed on re-run with no change. **Worth recording because the second one isolates it.** The #232 run also carried #125's Room/WorkManager deadlock, so that failure could be argued as fallout from a run already in trouble. The #235 run had no deadlock, took 1m07s, and failed only this — so this is its own flake and not a symptom of the hang. Neither PR touches `app/src/main` or `app/src/test`. Three sightings now, all on diffs that cannot explain them.
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 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#220