timothyandClaude Opus 4.8
dc5ceb5a14
Build ErsatzTV Image / CI image pin matches docker/ci (pull_request) Successful in 8s
Build ErsatzTV Image / Formatting (changed .cs conform to .editorconfig) (pull_request) Successful in 12s
Build ErsatzTV Image / Docs update reminder (pull_request) Successful in 13s
Build ErsatzTV Image / API docs in sync (OpenAPI + endpoint index) (pull_request) Successful in 1m29s
Build ErsatzTV Image / decisions.md append-only (pull_request) Failing after 12m6s
Build ErsatzTV Image / Functional E2E (curl contracts) (pull_request) Successful in 15m47s
Build ErsatzTV Image / Build & test (.NET) (pull_request) Successful in 18m54s
Build ErsatzTV Image / EF migration integrity (SQLite + MySql) (pull_request) Successful in 20m46s
Build ErsatzTV Image / Build & push image (amd64) (pull_request) Has been skipped
Second review pass returned BLOCKED on two findings introduced by the first fix commit. Both were right. BLOCKER 1 — the drain added for "return the connection to the pool" was unbounded. `response.Content.ReadAsByteArrayAsync()` buffers the WHOLE body, and it ran for every non-404 response. A server that ignores `Range: bytes=0-0` answers 200 with the entire file, so this would download at line rate into a byte[] on the streaming hot path for up to the 2s timeout -- strictly worse than the aborted socket it replaced, and it defeated the ResponseHeadersRead the probe deliberately uses. Now the single byte is read only on 206 (where the server honoured the range and the body really is one byte); any other status aborts the socket, which is much the cheaper evil. Two tests pin both directions; verified non-vacuous (restoring the unbounded drain fails the 200-with-body test). BLOCKER 2 — IRemoteStreamProber's doc-comment still described pre-fix behaviour. I had told the reviewer it was updated; it was not -- only the implementation's <remarks> had been. It claimed `false` on any 404 (now only a redirected one) and that every other outcome returns `true` (caller cancellation throws). Both clauses corrected, and the throwing contract is now documented with <exception>. Also fixed the reviewer's own follow-on finding: the cancellation rethrow it asked for reached HlsSessionWorker's catch-all, which logs a channel-level ERROR with a stack trace. The graceful TaskCanceledException/OperationCanceledException handler at :662 wraps only the inner ffmpeg block, not the mediator sends, so every client disconnect on a remote-streaming channel would have produced a spurious ERROR -- in exactly the logs a #350 cold-start investigation reads. Added a cancellation filter on the outer try that logs Information instead. Nit: stale SeedAll doc-comment now mentions the emby case. Deferred, per reviewer's explicit agreement: Plex-branch handler coverage (follow-up), and HEAD-with-GET-fallback. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>