Skip to content

MoQ: wait for the bot's broadcast before subscribing to it - #167

Merged
filipi87 merged 2 commits into
pipecat-ai:mainfrom
kixelated:claude/moq-wait-for-bot-broadcast
Aug 13, 2026
Merged

MoQ: wait for the bot's broadcast before subscribing to it#167
filipi87 merged 2 commits into
pipecat-ai:mainfrom
kixelated:claude/moq-wait-for-bot-broadcast

Conversation

@kixelated

Copy link
Copy Markdown
Contributor

What

Both of the bot-side subscribers — the Watch.Broadcast catalog/audio watcher and the transcript stream — fired on this._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_STREAM and neither retried, leaving the client connected but permanently silent:

subscribe start: id=0 broadcast=response/<id> track=transcript.json.z
subscribe start: id=1 broadcast=response/<id> track=catalog.json
announce:        broadcast=request/<id> active=true
subscribe error: id=1 ... track=catalog.json error=Received RESET_STREAM.
subscribe error: id=0 ... track=transcript.json.z error=Received RESET_STREAM.
announced:       broadcast=response/<id> active=true      <- bot arrives, too late

This doesn't affect the /start flow, where the server blocks on the bot's ready event before the browser ever connects.

How

Track the bot's broadcast announcement in a Signal and gate both subscribers on it. Watch.Broadcast already accepts an enabled signal, 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 --noEmit and parcel build clean.

(written by Opus 5)

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
kixelated force-pushed the claude/moq-wait-for-bot-broadcast branch from f8e8d49 to 9ff8594 Compare August 5, 2026 21:54
@kixelated
kixelated marked this pull request as ready for review August 10, 2026 17:40
@kixelated

Copy link
Copy Markdown
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.

@vipyne

vipyne commented Aug 11, 2026

Copy link
Copy Markdown
Member

I pushed a commit, lmk if it works for you @kixelated. it's intended to be paired with pipecat PR #5158

@vipyne
vipyne requested a review from filipi87 August 13, 2026 15:57

@filipi87 filipi87 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@filipi87
filipi87 merged commit 301bb6b into pipecat-ai:main Aug 13, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants