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

Spike: find out whether a running conversion's process can be killed under instrumentation #230

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

Filed from the 2026-09-05 e2e read of the instrumented suite on main @ 4b02294. A spike, not a test — see "Done means".

Reattachment exists so that a conversion surviving the app's death is picked up on relaunch. No test has ever killed a running conversion.

What is covered, and the one thing that is not

ReattachOnLaunchTest (8 tests) covers a job that finished while the ViewModel was gone, one whose staged file is missing, an ambiguous pair claiming one file, one still queued, one cancelled, and a pick the user has already made. All of them fabricate the job's terminal or queued state with EchoWorker and tags, then construct a fresh ViewModel.

None of them kills a process. The case reattachment is for — a conversion running when the app dies — has never been produced.

Why this is a spike rather than "add a test"

docs/defect-audit.md D3/D13 already record the blocker: am kill refuses a process holding a foreground service, so the forcing condition was never met. Filing "write a test for this" would re-file a known-blocked task and invite someone to rediscover the same wall.

What has not been done is a systematic look at whether any of the other routes works:

  • am kill variants, and whether --user or stopping the service first changes the refusal
  • am force-stop — kills, but also cancels WorkManager's own scheduling on some versions, which may make it a different scenario rather than this one
  • Process.killProcess(Process.myPid()) from inside the app process under instrumentation — kills the test runner with it, so it needs the two-process split the fixture provider already demonstrates is possible
  • adb shell kill -9 against the pid, from the instrumentation side
  • Whether WorkManager's own TestDriver can simulate the restart without a real death, and whether that would still be testing the thing

Done means

A written answer either way, in docs/e2e-read-findings.md or as a comment on ReattachOnLaunchTest:

  • a route that works, and a test using it, or
  • "these five were tried, each refused for this reason, so process death stays device-manual" — which is a successful outcome and closes D3/D13's open forcing condition with evidence rather than leaving it as an unexamined gap.

This is the same shape as #204's O3: a spike whose value is the recorded answer, and where "it cannot be done this way" is a result.

Not proposed

Weakening the foreground service to make the process killable. The foreground service is why the conversion survives at all; removing it to test the survival would be testing a different app.

_Filed from the 2026-09-05 e2e read of the instrumented suite on `main` @ `4b02294`. **A spike, not a test** — see "Done means"._ Reattachment exists so that a conversion surviving the app's death is picked up on relaunch. No test has ever killed a running conversion. ## What is covered, and the one thing that is not `ReattachOnLaunchTest` (8 tests) covers a job that **finished** while the ViewModel was gone, one whose staged file is missing, an ambiguous pair claiming one file, one still **queued**, one **cancelled**, and a pick the user has already made. All of them fabricate the job's terminal or queued state with `EchoWorker` and tags, then construct a fresh ViewModel. None of them kills a process. The case reattachment is *for* — a conversion running when the app dies — has never been produced. ## Why this is a spike rather than "add a test" `docs/defect-audit.md` **D3/D13** already record the blocker: `am kill` refuses a process holding a foreground service, so the forcing condition was never met. Filing "write a test for this" would re-file a known-blocked task and invite someone to rediscover the same wall. What has *not* been done is a systematic look at whether any of the other routes works: - `am kill` variants, and whether `--user` or stopping the service first changes the refusal - `am force-stop` — kills, but also cancels WorkManager's own scheduling on some versions, which may make it a different scenario rather than this one - `Process.killProcess(Process.myPid())` from inside the app process under instrumentation — kills the test runner with it, so it needs the two-process split the fixture provider already demonstrates is possible - `adb shell kill -9` against the pid, from the instrumentation side - Whether WorkManager's own `TestDriver` can simulate the restart without a real death, and whether that would still be testing the thing ## Done means **A written answer either way**, in `docs/e2e-read-findings.md` or as a comment on `ReattachOnLaunchTest`: - a route that works, and a test using it, **or** - *"these five were tried, each refused for this reason, so process death stays device-manual"* — which is a successful outcome and closes D3/D13's open forcing condition with evidence rather than leaving it as an unexamined gap. This is the same shape as #204's O3: a spike whose value is the recorded answer, and where "it cannot be done this way" is a result. ## Not proposed Weakening the foreground service to make the process killable. The foreground service is why the conversion survives at all; removing it to test the survival would be testing a different app.
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
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#230