feat(qmux): add server-side Session.accept() (JS)

[kixelated]

Closes #314.

js/qmux's Session could only ever be a client. The protocol logic was already role-aware, but #isServer was never assigned and the socket was not injectable, so there was no way to build a server session from an accepted WebSocket — a JS accept server had no equivalent of the ws:// fallback moq-relay serves alongside WebTransport.

API

import Session, { selectSubprotocol } from "@moq/qmux"

Deno.serve((req) => {
	const protocol = selectSubprotocol(req.headers.get("sec-websocket-protocol"), {
		protocols: ["moq-lite-04"],
		versions: { "moq-lite-04": null },
	})
	if (!protocol) return new Response("no supported protocol", { status: 400 })

	const { socket, response } = Deno.upgradeWebSocket(req, { protocol })
	const session = Session.accept(socket)  // a WebTransport, server-side
	handle(session)
	return response
})

Session.accept mirrors the Rust crate's qmux::ws::Server::accept. new Session(url) keeps the WebTransport constructor signature, so install() is unaffected.

Changes

• Session.accept(socket, options) takes a plain WebSocket, a WebSocketStream, or anything WebSocketStreamLike — so Deno.upgradeWebSocket, ws, and Bun.serve all work. The constructor now accepts a socket in place of a URL, which is what makes the role injectable.
• WebSocketStream.adopt() (@moq/web-socket-stream) wraps a socket that already exists. An accepted socket is typically already OPEN, so onopen has already fired and waiting for it would hang forever; opened now settles from readyState.
• selectSubprotocol() is the accept-side mirror of resolveSubprotocols. The host runs the handshake, so it — not the library — picks the subprotocol; this expands the same protocols + versions pair and returns the first wire form the client offered. Preference is ours, not the client's, matching qmux::ws::Server. It returns undefined on no match so the caller fails the upgrade: accepting with no subprotocol silently negotiates the legacy webtransport wire format and misreads every QMux frame.
• AcceptOptions.protocol stands in for hosts that don't report the negotiated subprotocol on the socket (Bun is one).

Verification

New interop-client Rust example, the mirror of the existing interop-server: a real Rust client drives a JS Session.accept server across qmux-00/01/02 — 1.2 MB in each direction with flow-control replenishment, bidi streams, datagrams, and a clean close. It runs in CI via just test.

Reverting #isServer = true fails that test immediately with Invalid stream ID direction, along with four unit tests, so the coverage is anchored to the fix rather than passing incidentally. just check and just test are green.

Notes

• The exports half of js/qmux: no server-side Session — can't accept a WebSocket (#isServer hardcoded, socket not injectable) #314 is not included. selectSubprotocol ships from the main entry, which removes the reason to reach for frame/credit/stream/varint; those stay private, consistent with Narrow QMux public API #313.
• The reporter retracted the motivation in a follow-up comment (the Deno bug they cited was closed as invalid) and offered to have the issue closed. This is built on the standalone merit — a JS accept server can now offer the same WebSocket fallback the relay does — not on the original diagnosis.

🤖 Generated with Claude Code

[sourcery-ai]

Sorry @kixelated, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[coderabbitai]

Warning

Review limit reached

@kixelated, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 44 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 38fbaaff-19c1-435b-86a7-ac2c14f4568d

📥 Commits

Reviewing files that changed from the base of the PR and between f0c64c1 and ab531f6.

📒 Files selected for processing (10)

• js/qmux/README.md
• js/qmux/src/index.ts
• js/qmux/src/session.test.ts
• js/qmux/src/session.ts
• js/qmux/src/subprotocol.test.ts
• js/qmux/tests/interop.test.ts
• js/web-socket-stream/README.md
• js/web-socket-stream/src/index.test.ts
• js/web-socket-stream/src/index.ts
• rs/qmux/examples/interop-client.rs

✨ Finishing Touches

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch claude/web-transport-314-83aa2f

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}