js/qmux: Session logs console.warn("abort", ...) on every application-initiated writer.abort()

[fperex]

Summary

Session calls console.warn("abort", e) from all three of its WritableStream sinks. A WritableStream sink's abort runs for any writer.abort(reason), including the ordinary application-initiated teardown of a stream, so this fires on healthy sessions and there is no way for a consumer to turn it off.

Present at HEAD in js/qmux/src/session.ts at lines 1375, 1683, 1763, and in the published 0.3.0 and 0.3.1. It has been there since the crate was added (a4786af, #191), so it reads like a debug leftover rather than a deliberate diagnostic.

abort: (e) => {
    console.warn("abort", e);
    this.#scheduler?.dropStream(streamId, e instanceof Error ? e : new Error("stream aborted"));
    this.#sendPriorityFrame({ type: "reset_stream", id: frame.id, code: VarInt.from(0), ... });
    ...
},

The three sites:

Line	Stream
1375	incoming (peer-created) bidi, send half
1683	createBidirectionalStream, send half
1763	createUnidirectionalStream

Why it matters in practice

moq's js/net routes Safari and Firefox onto qmux (js/net/src/connection/browser.ts disables WebTransport for both), and its stream teardown is Writer.reset(reason) calling writer.abort(reason). So every abort in normal operation prints a line into the user's console. The same teardown on Chrome, over native WebTransport, is silent, which makes it look browser-specific to whoever is reading the log.

A real example, from a Safari publisher against a local relay. Every one of these is qmux, none is the application:

[warn] abort Error: unexpected end of stream
#fillTo@http://localhost:5174/@fs/.../js/net/src/stream.ts:89:20
[warn] abort Error: unexpected end of stream
[warn] abort Error: unexpected end of stream
[warn] abort Error: RESET_STREAM: 0
#handleResetStream@.../@moq_qmux.js:2079:39
#recvFrame@.../@moq_qmux.js:1769:66
#onData@.../@moq_qmux.js:1753:48
#readLoop@.../@moq_qmux.js:1715:17

Two things make this expensive to be on the receiving end of:

1. The message is the bare word abort with no stream id, no direction, and no indication of which library emitted it. The only clue is the Error argument's own stack, which points at wherever the error was constructed, not at what aborted. In the example above that is a moq source file, so the natural reading is "moq bug", and qmux never appears in the line at all.
2. It is console.warn, so it survives production builds and shows up in end users' consoles and in any log capture the application does.

For what it is worth, tracking that first line down to qmux and then to a stream-resurrection race took a full instrumented A/B. Adding the stream id and direction to the message would have collapsed most of that. If the line stays in any form, something like `qmux: stream ${streamId} (${dir}) aborted by the application` would be a large improvement over abort. The neighbouring diagnostics in the same file already do this (qmux: keep-alive ping failed, qmux: control backlog ... exceeds high-water).

Repro

Nothing exotic is needed. Any application-initiated abort triggers it:

import Session from "@moq/qmux";

const session = new Session(url, { protocols: [...] });
await session.ready;

const { writable } = await session.createBidirectionalStream();
const writer = writable.getWriter();
await writer.write(new Uint8Array([1]));
await writer.abort(new Error("done with this stream")).catch(() => {});
// console: abort Error: done with this stream

Note the abort here is a deliberate, correct call by the application. Nothing has gone wrong at the transport level.

Suggested direction

Not prescribing a shape, but the options as I see them:

• Drop the three console.warn("abort", e) calls. An application-initiated abort is not an event the transport needs to narrate; the caller already knows, and the peer learns via RESET_STREAM.
• Or keep a diagnostic but make it identify itself and the stream, and put it behind whatever debug switch the rest of the library would use, so it does not reach production consoles by default.

Either way it would be worth a quick grep for other bare console.* calls on hot paths at the same time. session.ts currently also has console.error("Protocol violation:", error) and console.warn("serverCertificateHashes is not supported; trying anyway"), which are arguably fine since they are genuine faults, but they have the same "library writes to the app's console" property.

Environment

• @moq/qmux 0.3.0 and 0.3.1, and js/qmux/src/session.ts at moq-dev/web-transport HEAD (6176697)
• Reproduced on Safari 26.5, Firefox, and Chromium (forced onto the WebSocket path), macOS 15.5 arm64
• Consumer: moq-dev/moq js/net at dev ee4a0b49

Unrelated to this report, and mentioned only so it does not get filed twice: the two 0.3.0 bugs this investigation started from (a cancelled stream id being resurrected by an in-flight FIN, and #readLoop not normalizing Chromium's native WebSocketStream ArrayBuffer chunks) are both already fixed on main and released in 0.3.1, via #306 and #324. Verified against both versions. The only thing still outstanding is the logging above.

[fperex]

Consumer-side context for this, including the full instrumented trace and the version A/B: moq-dev/moq#2520.

[coderabbitai]

🔗 Related PRs

#247 - feat(qmux): prioritized send scheduler + @moq/web-socket-stream polyfill [closed]
#260 - fix(node): prevent use-after-free SIGSEGV on process exit [merged]
#280 - fix(qmux): datagram protocol-violation close (JS) + seal proto enums, rename transport halves [merged]
#285 - fix(qmux): stream-close race + propagate close reason to blocked Credit.claim() waiters (JS) [merged]
#306 - fix(qmux): honor RESET_STREAM final sizes [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[fperex]

Followed this all the way down. Three things to add: the mechanism is now pinned exactly, the line already prints in this repo's own CI, and two details in the report above were wrong — both corrected below.

Correction 1 — the warn is reachable only from an external abort

By quoting abort Error: RESET_STREAM: 0 with a stack through #handleResetStream, the report implies qmux might be aborting its own writable in reaction to a peer frame. It is not. qmux never calls .abort() on a send half anywhere — the only .abort( in js/qmux/src is in a test (session.test.ts:275), and there is no pipeTo/pipeThrough in the package at all.

Both places where qmux does tear a send half down use WritableStreamDefaultController.error() instead:

• #handleStopSending — session.ts:1494 — stream.error(...) with the STOP_SENDING: <code> error, then hand-rolls dropStream + reset_stream + maybeDeleteStreamFlow: exactly the work the sink's abort body does. The duplication reads deliberate.
• #teardown — session.ts:1809 — c.error(this.#closed) for every entry in #sendStreams.

Per WHATWG Streams that matters, because controller.error() runs WritableStreamDefaultControllerClearAlgorithms, which discards the sink's abort algorithm before the stream finishes erroring — so the sink's abort never runs. Measured on Node v24.16.0:

trigger	sink abort runs?
controller.error(e) — what qmux itself does	no
writer.abort(e) after controller.error(e)	no
writer.abort(reason) on a live stream	yes
readable.pipeTo(writable), source errors, default preventAbort	yes
writer.close()	no — runs close

Consequences, and they cut both ways:

• A clean session.close() with N open streams emits zero warns. So does a peer STOP_SENDING. The blast radius is narrower than the report implies.
• #handleResetStream (session.ts:1431-1487) only ever touches #recvStreams; it cannot reach a send half.
• So abort Error: RESET_STREAM: 0 is really this: qmux constructs that Error at session.ts:1483, delivers it on the readable via RecvStream.reset → controller.error, and the consumer hands the same instance back into the writable — js/net's #runBidis does .catch(err => stream.writer.reset(err)), and Writer.reset is writer.abort(reason).

That last point is the actual diagnosability defect, and it is worse than "the message is the bare word abort": the stack printed is always where the Error was constructed, never where the abort happened. That is why consecutive lines in the same log pointed into js/net/src/stream.ts for one and into qmux's own #handleResetStream for the next, while both were the same event.

It also closes a loose end from moq-dev/moq#2520: on 0.3.1 the publisher logs publish error: … STOP_SENDING: 0 with no accompanying abort line, even though #runTrack's catch does call stream.reset(e). qmux had already errored that send half in #handleStopSending, so the app's abort was a spec no-op — row 2 of the table above.

Net: the warn narrates exactly one thing — an application aborting a send half that qmux has not already errored. Never a transport fault.

It already prints in this repo's CI

No reproduction needed to see it. Run 30177376567 (2026-07-25, success), bun run --cwd js/qmux test:

##[group]src/session.test.ts:
(pass) Session integration (scripted peer) > a uni stream write produces a STREAM frame on the wire [7.00ms]
abort warn: cancel
      at <anonymous> (/home/runner/work/web-transport/web-transport/js/qmux/src/session.test.ts:275:26)

(pass) Session integration (scripted peer) > aborting after a write sends the transmitted byte count as final_size [4.00ms]

The emitting test is session.test.ts:267. It passes, and its name — "aborting after a write sends the transmitted byte count as final_size" — describes abort as correct, expected behavior. The library warns on a path its own suite treats as the happy path, and the stack it prints points at the test's new Error("cancel") rather than at qmux.

Deterministic reproduction of all three sites

Only site 1763 has any coverage today; 1375 and 1683 are untested. This drops into session.test.ts and uses the existing connect() / peerParams() / FakePeer harness — no browser, no network, no relay. Evidence only, not a proposed change.

test("REPRO-344 every abort sink warns on an ordinary application abort", async () => {
	const { session, peer } = connect();
	await session.ready;
	peer.send({ type: "transport_parameters", params: peerParams() });

	// session.ts:1763 — createUnidirectionalStream
	const uni = await session.createUnidirectionalStream();
	await uni.getWriter().abort(new Error("app teardown: uni"));

	// session.ts:1683 — createBidirectionalStream, send half
	const bi = await session.createBidirectionalStream();
	await bi.writable.getWriter().abort(new Error("app teardown: local bidi"));

	// session.ts:1375 — incoming peer-created bidi, send half
	peer.send({
		type: "stream",
		id: Stream.Id.create(0n, Stream.Dir.Bi, true),
		data: new Uint8Array([1]),
		fin: false,
	});
	const incoming = await session.incomingBidirectionalStreams.getReader().read();
	await incoming.value?.writable.getWriter().abort(new Error("app teardown: incoming bidi"));

	// Three RESET_STREAMs on the wire, three console.warn lines, zero faults.
	await waitFor(() => peer.count("reset_stream") === 3);
	session.close();
});

bun test src/session.test.ts -t "REPRO-344", on HEAD 6176697:

src/session.test.ts:
abort warn: app teardown: uni
      at <anonymous> (.../js/qmux/src/session.test.ts:290:35)

abort warn: app teardown: local bidi
      at <anonymous> (.../js/qmux/src/session.test.ts:294:43)

abort warn: app teardown: incoming bidi
      at <anonymous> (.../js/qmux/src/session.test.ts:304:56)

 1 pass
 0 fail

Every stack points into the test file — the new Error(...) line — and none names qmux, the stream id, or the direction.

Whatever the fix is, nothing is coupled to it

Checked so the decision doesn't need re-litigating:

• No test asserts on console. Nothing in js/qmux spies on, mocks, or captures console, and there is no bunfig.toml preload that could. The one test that emits a warn asserts only on reset.finalSize.
• No behavioral coupling. The console.warn is a pure side effect; the rest of each sink body (dropStream, sendPriorityFrame, map cleanup) does the protocol work.
• Nothing to gate it behind today. No logger module, no debug dependency, no env or globalThis flag, and no verbose/logLevel on SessionOptions, AcceptOptions, or Config.
• Nothing strips it. The build is plain tsc; there is no bundler or minifier anywhere in the repo, and js/common/package.ts deletes files and publishes dist/ as-is. Biome's lint/suspicious/noConsole is not enabled, so biome check js/qmux/src/session.ts returns zero diagnostics on a file with six console.* calls.

For contrast, rs/qmux routes its equivalent diagnostics through tracing::debug! with structured fields (session.rs:852, transport.rs:801, tls.rs:86), rs/ has no live println!/eprintln! outside tests, and web-transport-wasm — same browser target — never touches web_sys::console.

Correction 2 — provenance

The report credits a4786af (#191). That is wrong: a4786af is a rename (git show a4786af --name-status --find-renames gives R083 web-transport-ws/src/session.ts → qmux/src/session.ts), so the - lines are just the delete side of the move.

True origin is 9377f6a, #89, 2025-09-03 ("Add web-transport-trait and web-transport-ws"), which added all three in web-transport-ws/src/session.ts. That is 325 days, 26 commits to that file, 3 package renames, and all 12 published @moq/qmux versions including latest = 0.3.1. Notably the lines survived #247 rewriting the very block they sit in — git blame attributes the adjacent dropStream call to that commit while the console.warn above it still dates to the 2025 formatting pass.

Downstream: 26 call sites in one consumer

moq js/net @ a8411122. Writer.reset(reason) is this.#writer.abort(reason) (js/net/src/stream.ts:349) and Stream.abort(reason) calls it (:56), so every one of these lands on a qmux sink. Stream.close() uses writer.close() and is silent (:52).

Which qmux site each reaches: Stream.accept → 1375, Stream.open → 1683, Writer.open → 1763.

moq call site	context	qmux sink
lite/connection.ts:240	#sendSetup catch	1763
lite/connection.ts:252	#runBidis catch — the moq#2520 line	1375
lite/publisher.ts:248	runSubscribe, unknown broadcast	1375
lite/publisher.ts:313	runSubscribe catch	1375
lite/publisher.ts:325	runFetch, pre-lite-05 version gate	1375
lite/publisher.ts:332	runFetch, unknown broadcast	1375
lite/publisher.ts:351	runFetch catch	1375
lite/publisher.ts:404	#runTrack catch	1375
lite/publisher.ts:421	runTrackInfo, unknown track	1375
lite/publisher.ts:551	#runGroup catch — once per group	1763
lite/subscriber.ts:338 :339 :382 :448 :522 :575	subscribe / fetch / track teardown, all on Stream.open streams	1683
ietf/connection.ts:177 :205 :234, ietf/publisher.ts:106 :200 :240 :310, ietf/subscriber.ts:194 :276 :314	the moq-ietf equivalents	mixed

26 sites across 6 files, each warning whenever qmux has not already errored that send half. All three sinks are live. #runGroup (publisher.ts:519) opens one uni stream per group via Writer.open (:522) and resets it on error (:551), so that one scales with group rate rather than with session count.

The sharpest of these: runSubscribe (:248), runFetch (:332) and runTrackInfo (:421) answer "no such broadcast/track" by resetting the stream — a routine protocol answer, and moq logs each at console.debug:

console.debug(`publish unknown: broadcast=${msg.broadcast}`);
stream.writer.reset(new Error("not found"));

The application deliberately classifies that event as debug — ietf/publisher.ts:309 does the same for subscribe_namespace stream error. qmux then logs the same event at console.warn, one line later, and the application has no way to override it.

js/net happens to use no pipeTo, so the pipeTo row of the sink table further up is latent rather than active here — but any consumer that pipes into a qmux writable gets the warn with no abort anywhere in their own code.

---

Everything above is on HEAD 6176697 / @moq/qmux@0.3.1. Happy to leave the report as-is if the conclusion is "keep it, prefixed and behind a flag" — the point of this comment is only that the evidence is now unambiguous about what triggers it and that nothing is coupled to whichever way it goes.