Skip to content

compute-client: multiplex one command stream across two runtimes - #38388

Draft
antiguru wants to merge 1 commit into
mh/interactive-02-sharingfrom
mh/interactive-03-multiplex
Draft

compute-client: multiplex one command stream across two runtimes#38388
antiguru wants to merge 1 commit into
mh/interactive-02-sharingfrom
mh/interactive-03-multiplex

Conversation

@antiguru

Copy link
Copy Markdown
Member

Third of eight PRs splitting #37770. Stacks on #38387. Tracked by CPU-216.

A replica running two compute runtimes still speaks one compute protocol to the controller. This adds the multiplexer that fans a single command stream out to both and merges their responses into one, so neither the controller nor the protocol learns that the replica is split.

Routing follows collection identity rather than command kind. Lifecycle commands go to both runtimes, a dataflow goes to the runtime that will host it, and AllowCompaction for a maintained collection is broadcast to both because the interactive runtime may be reading a published copy of it. Frontier reports are forwarded only from the owning runtime, since the controller keeps one frontier stream per collection and two reporters would race and regress it. Peek responses are forwarded verbatim, because exactly one runtime answers a peek.

Inert: nothing constructs a multiplexer. Independent of #38386 and #38387; it sits above them only to keep the stack linear.

@antiguru
antiguru force-pushed the mh/interactive-03-multiplex branch from 92a68e1 to 1db2f7e Compare August 21, 2026 11:23
@antiguru
antiguru force-pushed the mh/interactive-03-multiplex branch from 1db2f7e to b6ef7c0 Compare August 21, 2026 13:24
@antiguru
antiguru force-pushed the mh/interactive-03-multiplex branch from b6ef7c0 to 017ca4b Compare August 21, 2026 13:42
@antiguru
antiguru requested a review from DAlperin August 21, 2026 13:46
@antiguru
antiguru force-pushed the mh/interactive-03-multiplex branch from 017ca4b to 92b0861 Compare August 21, 2026 14:31
A replica running two compute runtimes still speaks one compute protocol to the
controller. This adds the multiplexer that fans a single command stream out to
both and merges their responses back into one, so neither the controller nor the
protocol learns that the replica is split.

Routing follows collection identity rather than command kind. Lifecycle commands
go to both runtimes, a dataflow goes to the runtime that will host it, and
`AllowCompaction` for a maintained collection is broadcast to both because the
interactive runtime may be reading a published copy of it. Frontier reports are
forwarded only from the runtime that owns the collection, since the controller
keeps one frontier stream per collection and two reporters would race and
regress it. Peek responses are forwarded verbatim without dedup, because a peek
is answered by exactly one runtime.

Nothing constructs a multiplexer yet, so the module is inert. Its tests cover
the routing table, the broadcast, ownership eviction, and that `recv` loses no
message when both sides are ready.

Tests are out of line in `multiplex/tests.rs`, per the convention in
`src/compute/AGENTS.md`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@antiguru
antiguru force-pushed the mh/interactive-03-multiplex branch from 92b0861 to c595599 Compare August 21, 2026 17:54
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.

1 participant