Stop looking up a recording that has been thrown away

[revtex]

What this fixes

Reported from a real session: a track was recorded for 285 ms, discarded as too short, and four seconds later the log said "Spotify" had no metadata for Icona Pop - I Love It (feat. Charli XCX) — which reads as the track matching having failed. It had not. The guard refused to tag that recording with Thank Me, which is exactly its job. What was wrong is that the lookup was still running at all.

19:09:46.731 [INF] Recording Icona Pop - I Love It (feat. Charli XCX).
19:09:47.016 [INF] Recording Able Heart - Thank Me.
19:09:47.024 [INF] Discarded Icona Pop …: shorter than 60s.
19:09:47.295 [DBG] Spotify reported nothing at all (204 No Content) while Icona Pop … was detected; asking again.
19:09:48.590 [DBG] Spotify reported Thank Me while Icona Pop … was detected; asking again.
19:09:50.862 [INF] "Spotify" had no metadata for Icona Pop - I Love It (feat. Charli XCX).

Nothing joined that lookup — FinaliseAsync returns on the too-short and silent branches before AwaitEnrichmentAsync, deliberately, so a fragment never waits on a provider — and nothing stopped it either. It spent several seconds asking about a song that had already ended, against a rate limit shared with the recording that replaced it, and reported a missing tag on a file that was never written. Worse where the answer carries no track at all: such a lookup can run the thirty-attempt no-track budget out and stand the session's advertisement handling down, on the evidence of a track that had already finished.

What changed

The lookup belongs to the recording rather than to the session. RecordingSession creates a cancellation source per recording, linked to its own token, and hands it to the TrackRecorder with the task; the recorder cancels it on the branches where it decides no file will exist.

It cannot hang off the track boundary instead: every normal recording is finalised after its song has ended — that is when the tags are joined — so cancelling in StopCurrentRecorder would strip the tags off everything.

Travelling with it:

• Cover art the lookup had already fetched is deleted when the recording is discarded. Only the already-recorded branch ever cleaned one up, so every short recording that had enriched in time leaked an image into %TEMP%.
• CoverArtFetcher deletes a half-written image when the fetch is cancelled mid-write — the path is lost with the exception. Cancellation only became reachable there with this change.
• CancelEnrichment swallows ObjectDisposedException: a session torn down while a recording is still finalising disposes the recorder from one thread while FinaliseAsync decides on the other, and cancelling an already-disposed source would surface as "Recording X failed" on a recording that was merely being tidied away.

Tests

911/911 green, build clean with analyzers as errors. Four new cases:

• Record_Discarded_StopsTheMetadataLookup — both discard outcomes, too short and silent.
• Record_ShorterThanTheMinimum_DeletesCoverArtTheLookupAlreadyFetched
• Record_Captured_KeepsTheCoverArtAndTheLookup — the other half of the rule: a kept recording still gets its art, and its lookup is not cancelled.
• Session_DiscardingAShortRecording_CancelsOnlyThatTracksLookup — asserts the next track's lookup is still live, which is what makes this a per-recording cancellation rather than the session's.

Not fixed here

The reason the fragment existed: the media session reports the previous track's properties with IsPlaying already true when playback starts from stopped, so the song that actually started loses its first few hundred milliseconds to the discarded recorder's Prime(). Fixing that changes what audio a recording contains — a settle window alone would make the clipping worse, and keeping the buffer trades it for an advertisement's tail bleeding into the next track — so it wants deciding on its own.

🤖 Generated with Claude Code