MoQ: wait for the bot's broadcast before subscribing to it - #167
Merged
filipi87 merged 2 commits intoAug 13, 2026
Conversation
kixelated
force-pushed
the
claude/moq-wait-for-bot-broadcast
branch
from
August 4, 2026 00:43
237dd75 to
f8e8d49
Compare
This was referenced Aug 4, 2026
Merged
Draft
The transcript track subscribed as soon as the connection was established, which assumes the bot is already on the relay. It isn't always: when the bot is started in response to our own announcement, its broadcast appears strictly after ours, so the stream was reset and never retried — leaving the client connected but silent. Gate it on the announcement instead, read off `Reload` rather than the established session so the gate spans reconnects. Only this track needs it. `Watch.Broadcast` has gated its own subscribe on `conn.announced(name)` since moq-dev/moq#2199, so the catalog and audio are already covered; the transcript goes straight through `@moq/net` with no wrapper. Co-Authored-By: Claude <noreply@anthropic.com>
kixelated
force-pushed
the
claude/moq-wait-for-bot-broadcast
branch
from
August 5, 2026 21:54
f8e8d49 to
9ff8594
Compare
kixelated
marked this pull request as ready for review
August 10, 2026 17:40
vipyne
approved these changes
Aug 10, 2026
Contributor
Author
|
Oh and I'm working on a better API for this, because yeah it's kind of gross. But I'll submit a separate PR for that. |
Member
|
I pushed a commit, lmk if it works for you @kixelated. it's intended to be paired with pipecat PR #5158 |
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
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.
What
Both of the bot-side subscribers — the
Watch.Broadcastcatalog/audio watcher and the transcript stream — fired onthis._reload.established, i.e. as soon as the connection came up. That assumes the bot is already publishing on the relay.It isn't always. When the bot is started in response to the client's own announcement, its broadcast necessarily appears after ours. The relay resets a subscribe to a path nobody publishes, so both streams died with
RESET_STREAMand neither retried, leaving the client connected but permanently silent:This doesn't affect the
/startflow, where the server blocks on the bot's ready event before the browser ever connects.How
Track the bot's broadcast announcement in a
Signaland gate both subscribers on it.Watch.Broadcastalready accepts anenabledsignal, and the transcript effect re-runs when the signal flips — so each subscribes once the broadcast is really there, and re-subscribes if it goes away and comes back.Testing
Verified against a bot that starts on demand, so its broadcast is guaranteed to appear after the client's. Before: both subscribes reset, no transcript, no audio. After: catalog fetch succeeds, transcript renders,
sync[audio]shows the player consuming frames.tsc --noEmitandparcel buildclean.(written by Opus 5)