The ticket asked for two things. One of them is not reachable from the JVM, and saying so is most of the value here.
probeForConcat's catch arm cannot be provoked on this runtime
Robolectric's MediaExtractor never throws from setDataSource. Measured across four input shapes:
input
result
unregistered content:// authority
no throw, trackCount = 0
missing file://
no throw, trackCount = 0
a file of garbage bytes
no throw, trackCount = 0
http:// URL
no throw, trackCount = 0
So a failed read arrives as an empty track list rather than an exception, and reaches the same ConcatInput(null, null, 0, 0, 0) by the other road. The catch stays covered only by ConcatEngineTest on a device, and the test file says so rather than implying the arm is handled. My first draft's KDoc claimed the opposite; the mutation caught it — rethrowing from the catch left the test green.
What was genuinely missing is the span between the two halves
Both halves were already covered, and neither reached the other:
MediaProbeTrackWalkTest pins what concatInputFrom makes of a track list.
ConcatPlannerTest's an unknown codec is not treated as a match pins what the planner does with a hand-builtConcatInput(video = null).
The planner's safety rests on the probe really producing that shape, and the hand-built fixture would go on passing if it stopped.
Measured, not claimed:
mutation
ConcatPlannerTest
this test
concatInputFrom's initial video → non-null placeholder
green
red
drop the planner's video null guard
red
red
The second row is why this PR does not claim credit for the guard itself — that half was already held.
The coupling, written down
ConcatPlanner guards video against a null codec (ConcatStrategy.kt:51) and audio not at all (:54). That asymmetry is correct.MediaProbe.shortName returns a non-null String, so a null audioCodec means the track is absent and two clips with no audio genuinely match; a null videoCodec means absent or unreadable. The audio check is safe because the video guard fires first on a clip nothing could read — and nothing held that.
Gate
Full gate green. 555 → 556 JVM tests, 0 failures. No production code changed.
Closes #170. Stacked on #180.
The ticket asked for two things. **One of them is not reachable from the JVM, and saying so is most of the value here.**
### `probeForConcat`'s catch arm cannot be provoked on this runtime
Robolectric's `MediaExtractor` never throws from `setDataSource`. Measured across four input shapes:
| input | result |
|---|---|
| unregistered `content://` authority | no throw, `trackCount = 0` |
| missing `file://` | no throw, `trackCount = 0` |
| a file of garbage bytes | no throw, `trackCount = 0` |
| `http://` URL | no throw, `trackCount = 0` |
So a failed read arrives as an empty track list rather than an exception, and reaches the same `ConcatInput(null, null, 0, 0, 0)` by the other road. The catch stays covered only by `ConcatEngineTest` on a device, and the test file **says so** rather than implying the arm is handled. My first draft's KDoc claimed the opposite; the mutation caught it — rethrowing from the catch left the test green.
### What was genuinely missing is the span between the two halves
Both halves were already covered, and neither reached the other:
- `MediaProbeTrackWalkTest` pins what `concatInputFrom` makes of a track list.
- `ConcatPlannerTest`'s `an unknown codec is not treated as a match` pins what the planner does with a **hand-built** `ConcatInput(video = null)`.
The planner's safety rests on the probe really producing that shape, and the hand-built fixture would go on passing if it stopped.
Measured, not claimed:
| mutation | `ConcatPlannerTest` | this test |
|---|---|---|
| `concatInputFrom`'s initial `video` → non-null placeholder | green | **red** |
| drop the planner's video null guard | red | red |
The second row is why this PR does not claim credit for the guard itself — that half was already held.
### The coupling, written down
`ConcatPlanner` guards video against a null codec (`ConcatStrategy.kt:51`) and audio not at all (`:54`). **That asymmetry is correct.** `MediaProbe.shortName` returns a non-null `String`, so a null `audioCodec` means the track is *absent* and two clips with no audio genuinely match; a null `videoCodec` means absent *or* unreadable. The audio check is safe because the video guard fires first on a clip nothing could read — and nothing held that.
### Gate
Full gate green. 555 → 556 JVM tests, 0 failures. No production code changed.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #170. Stacked on #180.
The ticket asked for two things. One of them is not reachable from the JVM, and saying so is most of the value here.
probeForConcat's catch arm cannot be provoked on this runtimeRobolectric's
MediaExtractornever throws fromsetDataSource. Measured across four input shapes:content://authoritytrackCount = 0file://trackCount = 0trackCount = 0http://URLtrackCount = 0So a failed read arrives as an empty track list rather than an exception, and reaches the same
ConcatInput(null, null, 0, 0, 0)by the other road. The catch stays covered only byConcatEngineTeston a device, and the test file says so rather than implying the arm is handled. My first draft's KDoc claimed the opposite; the mutation caught it — rethrowing from the catch left the test green.What was genuinely missing is the span between the two halves
Both halves were already covered, and neither reached the other:
MediaProbeTrackWalkTestpins whatconcatInputFrommakes of a track list.ConcatPlannerTest'san unknown codec is not treated as a matchpins what the planner does with a hand-builtConcatInput(video = null).The planner's safety rests on the probe really producing that shape, and the hand-built fixture would go on passing if it stopped.
Measured, not claimed:
ConcatPlannerTestconcatInputFrom's initialvideo→ non-null placeholderThe second row is why this PR does not claim credit for the guard itself — that half was already held.
The coupling, written down
ConcatPlannerguards video against a null codec (ConcatStrategy.kt:51) and audio not at all (:54). That asymmetry is correct.MediaProbe.shortNamereturns a non-nullString, so a nullaudioCodecmeans the track is absent and two clips with no audio genuinely match; a nullvideoCodecmeans absent or unreadable. The audio check is safe because the video guard fires first on a clip nothing could read — and nothing held that.Gate
Full gate green. 555 → 556 JVM tests, 0 failures. No production code changed.
🤖 Generated with Claude Code