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

R6 — publish() leaves the SAF-created empty document at the user's chosen name when openOutputStream fails #15

New Issue
Closed
opened 2026-08-23 03:44:43 +00:00 by JMR-dev · 1 comment
JMR-dev commented 2026-08-23 03:44:43 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Finding R6 from the overnight max-effort review (Fable lead, Opus sub-agents). Full report: scratchpad/overnight/REVIEW.md.

R6 — publish() leaves the SAF-created empty document at the user's chosen name when openOutputStream fails

severity: medium
verdict: CONFIRMED
where: app/src/main/java/org/libremediaconverter/convert/OutputPublisher.kt:114-120 (D4 fix, dbfc463)
scenario: Save -> provider fails to hand out a write stream (cloud provider dropped between picker and write; null return -> error()). Both paths are before the try, so deletePartialOutput never runs — but ACTION_CREATE_DOCUMENT already created the document, so a zero-byte file stays at the user's chosen name while the UI says "Could not save the file". The KDoc's justification ("nothing has been written at that point, so there is nothing of ours to remove") is contradicted by the fix's own test fixture (OutputPublisherPublishTest.kt:185-188: every destination starts as an existing empty document).
evidence: Reviewer probes on the unmodified fixture: PROBE-THROW/PROBE-NULL both end destination exists=true length=0, deletes=[]. destinationIsKnownEmpty returns true in this fixture (proved by the sibling partial-copy test), so the existing guard would already authorise the cleanup. Lead read publish() and confirmed the open is outside the guarded region.
fix: Move openOutputStream inside the guarded region (compute destinationWasEmpty, then try/catch around open+copy). Decide whether "provider would not open it" is worth cleaning at all — a provider that cannot open may also refuse to delete, which is already deletePartialOutput's documented no-op path.
risk: Low; the two existing safety bounds (document URIs only, positively-empty only) apply unchanged. JVM-testable — the probes invert into regression tests.

Cut: above — worked autonomously overnight.

🤖 Generated with Claude Code

_Finding **R6** from the overnight max-effort review (Fable lead, Opus sub-agents). Full report: `scratchpad/overnight/REVIEW.md`._ ### R6 — publish() leaves the SAF-created empty document at the user's chosen name when openOutputStream fails severity: medium verdict: CONFIRMED where: app/src/main/java/org/libremediaconverter/convert/OutputPublisher.kt:114-120 (D4 fix, dbfc463) scenario: Save -> provider fails to hand out a write stream (cloud provider dropped between picker and write; null return -> error()). Both paths are before the try, so deletePartialOutput never runs — but ACTION_CREATE_DOCUMENT already created the document, so a zero-byte file stays at the user's chosen name while the UI says "Could not save the file". The KDoc's justification ("nothing has been written at that point, so there is nothing of ours to remove") is contradicted by the fix's own test fixture (OutputPublisherPublishTest.kt:185-188: every destination starts as an existing empty document). evidence: Reviewer probes on the unmodified fixture: PROBE-THROW/PROBE-NULL both end destination exists=true length=0, deletes=[]. destinationIsKnownEmpty returns true in this fixture (proved by the sibling partial-copy test), so the existing guard would already authorise the cleanup. Lead read publish() and confirmed the open is outside the guarded region. fix: Move openOutputStream inside the guarded region (compute destinationWasEmpty, then try/catch around open+copy). Decide whether "provider would not open it" is worth cleaning at all — a provider that cannot open may also refuse to delete, which is already deletePartialOutput's documented no-op path. risk: Low; the two existing safety bounds (document URIs only, positively-empty only) apply unchanged. JVM-testable — the probes invert into regression tests. --- **Cut:** `above` — worked autonomously overnight. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
JMR-dev commented 2026-08-23 04:52:42 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Fixed in #48 (merged). Each fix is pinned by a mutation that was applied and reverted individually — the failure text is in the PR body. Suite 257 -> 276, 0 failures.

Fixed in #48 (merged). Each fix is pinned by a mutation that was applied and reverted individually — the failure text is in the PR body. Suite 257 -> 276, 0 failures.
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 above-cut confirmed documentation sev:medium
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#15