Open the save dialog with the type the job produced #215

Merged
JMR-dev merged 9 commits from test/retry-save-mime into main 2026-09-06 01:18:57 +00:00
JMR-dev commented 2026-09-03 00:02:59 +00:00 (Migrated from github.com)

Closes #201.

The gap

ConverterScreen.kt:80 had never taken its left-hand side:

val destinationMime = state.pendingSave()?.mimeType ?: settings.spec.mimeType

Its comment records what the line is for — a retry after a failed save must open with the type its first attempt used, because the fallback beside it is the current picker, which a reattached job never set. So the untested half is the fix, and the tested half is the fallback it was added to stop being used.

It withdraws a named exemption rather than working around it

FailedSaveRetryTest's KDoc listed this line under "Not asserted here, so each is a decision rather than an omission":

It lives in the entry point, above the ScreenContent seam, and reaching it needs a real ViewModel inside a composition.

True when written. AdaptiveShellTest (#173) then established composing the real screens with real ViewModels, and #200 added the two ShadowActivity mechanics for reading what a launcher launched. The reason the exemption gave no longer holds, so it is withdrawn in the same change rather than left to be taken at face value — the shape of #141 revising #84's boundary.

Fixture

The job is reattached rather than run, because the screen composes its own ViewModel through viewModel() and nothing can be injected. That is also the case the line exists for: a reattached job's spec "was never in these settings at all".

The test asserts the two mime types differ, as well as which one is used. Without that, the assertion would pass just as well against the fallback if the fixture ever drifted onto MP4.

Acceptance

Mutation: collapse :80 to settings.spec.mimeType → red. Run and restored.

Unrelated, but it turned up here: #159 now reproduces locally

The full suite failed once in six runs on OutputPublisherStagingTest:184. The isolating experiment says it is not this change:

result
3 runs with the new test all green
3 runs with the file removed one failure

That is a change in the ticket's own terms — #159 records it as a CI-only symptom ("a loaded CI runner is where it shows"), and it is now observable on this host as the suite has grown. Recorded on the issue.

Verification

testDebugUnitTest (full suite) + ktlintCheck + detekt + lintDebug — green.

🤖 Generated with Claude Code

Closes #201. ## The gap `ConverterScreen.kt:80` had never taken its left-hand side: ```kotlin val destinationMime = state.pendingSave()?.mimeType ?: settings.spec.mimeType ``` Its comment records what the line is for — a retry after a failed save must open with the type its **first** attempt used, because the fallback beside it is the current picker, which a reattached job never set. So the untested half is the fix, and the tested half is the fallback it was added to stop being used. ## It withdraws a named exemption rather than working around it `FailedSaveRetryTest`'s KDoc listed this line under "Not asserted here, so each is a decision rather than an omission": > It lives in the entry point, above the `ScreenContent` seam, and reaching it needs a real ViewModel inside a composition. True when written. `AdaptiveShellTest` (#173) then established composing the real screens with real ViewModels, and #200 added the two `ShadowActivity` mechanics for reading what a launcher launched. **The reason the exemption gave no longer holds**, so it is withdrawn in the same change rather than left to be taken at face value — the shape of #141 revising #84's boundary. ## Fixture The job is reattached rather than run, because the screen composes its own ViewModel through `viewModel()` and nothing can be injected. That is also the case the line exists for: a reattached job's spec "was never in these settings at all". The test asserts the two mime types **differ**, as well as which one is used. Without that, the assertion would pass just as well against the fallback if the fixture ever drifted onto MP4. ## Acceptance Mutation: collapse `:80` to `settings.spec.mimeType` → **red**. Run and restored. ## Unrelated, but it turned up here: #159 now reproduces locally The full suite failed once in six runs on `OutputPublisherStagingTest:184`. The isolating experiment says it is **not** this change: | | result | |---|---| | 3 runs **with** the new test | all green | | 3 runs **with the file removed** | one failure | That is a change in the ticket's own terms — #159 records it as a CI-only symptom ("a loaded CI runner is where it shows"), and it is now observable on this host as the suite has grown. Recorded on the issue. ## Verification `testDebugUnitTest` (full suite) + `ktlintCheck` + `detekt` + `lintDebug` — green. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.