fix(video): escalate live reopen exhaustion for URL sources too - #343
Open
tschuegy wants to merge 1 commit into
Open
fix(video): escalate live reopen exhaustion for URL sources too#343tschuegy wants to merge 1 commit into
tschuegy wants to merge 1 commit into
Conversation
Both reopen-exhaustion sites (the barren-cycle cap in handlePumpFinished and the attempt cap at the end of performLiveReopen) halted production and published onLiveSourceReset only for the .customFactory transport superuser404notfound#199 introduced. A URL-source live session that exhausted its reopen budget hit the same terminal state with neither: the provider kept advertising blocking reloads it could never satisfy, the playlist stayed frozen, and the host was never asked to retune — the exact zombie window superuser404notfound#199 closed for engine-created ingest readers, still open on the most common transport. Extract the escalation decision as a pure function covering every reopenable transport (.none stays out: it delegates to host retune before any reopen begins, and escalating it again would double-signal liveSourceReset) and use it at both sites. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Both live reopen-exhaustion sites escalate only for the
.customFactorytransport that #199 introduced:handlePumpFinished("live source produced no segments across N reopen cycles; giving up"), andperformLiveReopen("live reopen FAILED after N attempts; source considered permanently lost").A URL-source live session that exhausts its reopen budget reaches the same terminal state with neither
markLiveProductionHalted()noronLiveSourceReset: the provider keeps advertising blocking reloads it can never satisfy (the -15410 shape the halt latch exists for), the playlist stays frozen, and the host is never asked to retune. That is exactly the zombie window #199 closed for engine-created ingest readers — still open on the most common transport.Found while tracing a field freeze (same session as #340/#341/#342): the incident itself died through the live-
muxerFailedhole #341 covers, but this adjacent exhaustion path has the identical failure shape for URL sources whose reopens run dry.Fix
Extract the escalation decision as a pure function,
liveReopenExhaustionEscalatesToHost(transport:), covering every reopenable transport, and use it at both sites..nonedeliberately stays out: a transport-less source delegates to host retune before any reopen begins, and escalating it again would double-signalliveSourceReset.Behavior for
.customFactoryis unchanged;.urlnow halts + signals on exhaustion instead of zombifying.Tests
Pinned in
Issue199RerouteRecoveryTestsnext to the existing transport-decision pins:.urland.customFactoryescalate on exhaustion;.nonenever reaches the escalation.🤖 Generated with Claude Code