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

getForegroundInfo is dead in both workers: nothing in this app enqueues expedited work #252

New Issue
Closed
opened 2026-09-06 19:20:36 +00:00 by JMR-dev · 0 comments
JMR-dev commented 2026-09-06 19:20:36 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Found by the first-ever instrumented coverage measurement (2026-09-06). Of the 32 lines no
suite reaches — JVM or device — these ten are the largest single cluster:

app/src/main/java/org/libremediaconverter/work/ConversionWorker.kt:342-346
app/src/main/java/org/libremediaconverter/work/ConcatWorker.kt:132-136

Both are override suspend fun getForegroundInfo(): ForegroundInfo.

They are not a test gap, and that is the finding

The live foreground path does not go through them. ConversionWorker:103 calls
setForeground(foregroundInfo(...)) directly and ConversionWorker:278 calls
setForegroundAsync(foregroundInfo(...)); ConcatWorker:71 builds its ForegroundInfo inline.
All of those are covered.

getForegroundInfo() is WorkManager's hook for expedited work. Nothing in this app enqueues
any: setExpedited and OutOfQuotaPolicy appear nowhere in app/src/main. So these ten lines
cannot execute in production, and no test — unit or instrumented — should be written to reach them.

The decision, which is a product one

  1. Delete both overrides. They are inherited members with a default; nothing breaks.
  2. Keep them and say why, in the KDoc, as the thing that makes a later setExpedited safe.
  3. Actually enqueue expedited work — conversions are user-initiated and would start sooner.
    That is a feature, and if it is taken these ten lines get covered by the tests that already
    exist rather than by new ones.

Option 3 is the only one that turns this into a test question, and it should be decided before
any test is written.

Acceptance criterion

Whichever is chosen, the coverage report must stop listing these ten lines as unreached — either
because they are gone, or because a request now carries setExpedited and the existing worker
tests drive them. A KDoc-only answer (option 2) closes this as no action, recorded, the way
docs/coverage-read-findings.md F4 does.

Found by the first-ever instrumented coverage measurement (2026-09-06). Of the **32 lines no suite reaches — JVM or device — these ten are the largest single cluster**: ``` app/src/main/java/org/libremediaconverter/work/ConversionWorker.kt:342-346 app/src/main/java/org/libremediaconverter/work/ConcatWorker.kt:132-136 ``` Both are `override suspend fun getForegroundInfo(): ForegroundInfo`. ## They are not a test gap, and that is the finding The live foreground path does not go through them. `ConversionWorker:103` calls `setForeground(foregroundInfo(...))` directly and `ConversionWorker:278` calls `setForegroundAsync(foregroundInfo(...))`; `ConcatWorker:71` builds its `ForegroundInfo` inline. All of those are covered. `getForegroundInfo()` is WorkManager's hook for **expedited** work. Nothing in this app enqueues any: `setExpedited` and `OutOfQuotaPolicy` appear nowhere in `app/src/main`. So these ten lines cannot execute in production, and no test — unit or instrumented — should be written to reach them. ## The decision, which is a product one 1. **Delete both overrides.** They are inherited members with a default; nothing breaks. 2. **Keep them and say why**, in the KDoc, as the thing that makes a later `setExpedited` safe. 3. **Actually enqueue expedited work** — conversions are user-initiated and would start sooner. That is a feature, and if it is taken these ten lines get covered by the tests that already exist rather than by new ones. Option 3 is the only one that turns this into a test question, and it should be decided before any test is written. ## Acceptance criterion Whichever is chosen, the coverage report must stop listing these ten lines as unreached — either because they are gone, or because a request now carries `setExpedited` and the existing worker tests drive them. A KDoc-only answer (option 2) closes this as **no action, recorded**, the way `docs/coverage-read-findings.md` F4 does.
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
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#252