[nissa-seru]

A redaction of a server's text no longer throws when it can't read the configuration it redacts with; it withholds the text instead. On a legacy MCPL connection, that throw rejected a reconnect with nothing to catch it, and two transport listeners threw it inside I/O callbacks.

Problem

A record of a server's text is redacted with the strings its configuration knows to be credentials (redactServerText, serverTextRedactor in src/mcpl/protocol-family.ts). Reading those strings can throw. A legacy stdio MCPL server's connection gets a copy of its configuration whose env is a getter. The getter derives the child's reaction baseline at each spawn, and it throws while the Discord awareness ledger can't be read, rather than give a partial baseline (getPlacedReactionBaseline). The redaction then throws too. Four of the legacy connection's records redact with that copy:

• A reconnect attempt's failure (reconnectOnce). On main, I connected a legacy stdio server with reconnect: true, made the ledger unreadable, and ended the child. The reconnect's spawn read the getter and failed. Its catch redacted that failure with the same configuration, which threw the same error, and:
  • the attempt rejected with nothing to catch it. The process got unhandledRejection DiscordAwarenessAccountingError: … reaction-baseline ledger read …, which by Node's default ends the process;
  • the connection emitted no reconnect-failed, and the attempt stayed in flight. Two seconds after the ledger could be read again, the server was still down, with no attempt since;
  • the framework's stop() then rejected with the same error, since close() waits on that attempt.
• The 'error' listener a handshake leaves once it has settled (logAfterSettled). I reached it as its test does, with a WebSocket server that refuses initialize and then sends a malformed frame, and a configuration whose env getter throws. The throw escaped as an uncaughtException, from inside the socket's I/O callback. The framework gives the getter only to stdio configurations, so I built that configuration for the probe.
• The listener on a transport closed before it served, which has the same shape.
• The initial connect's failure with reconnect: true (connectWithReconnect). It rejected the connect instead of returning the stub that retries. The framework reads the ledger itself before a legacy connect, so this one meets an unreadable ledger only if the ledger breaks after that read and before the connect's failure is recorded.

Changes

• serverTextRedactor, which redactServerText uses, builds its patterns inside a try. When the configuration can't be read, that call returns WITHHELD_TEXT, [withheld: the server's configuration couldn't be read to redact this], in place of the text, and the next call reads the configuration again. Its doc and redactServerText's say so.
• serverCredentialPatterns reads the configuration's url before the try that parses it, so a url that can't be read withholds the text too, rather than reading as absent.
• The framework's every-server redactor (everyServerRedactor), for text that may come from any configured server, withholds the same way when any server's configuration can't be read.
• The comment beside the framework's ledger read before a legacy connect says what a ledger that breaks after that read leads to (What a host notices).
• A changelog fragment.

What each part is for

This change keeps a redaction of a server's text from throwing when it can't read the configuration it redacts with, so recording the text can't break what records it. Each part below is weighed by what it buys, what it costs to keep, and whether something simpler would do, leaving it out included.

• The try in serverTextRedactor covers every caller at once: the four legacy records, and every other place that records a server's text. A try at each record would repeat it, and a record added later would need its own. Without the configuration the text can't be redacted, so withholding it is the one answer that leaks nothing.
• Reading url before its parse's try keeps a configuration whose url can't be read from being redacted without the url's strings. That catch is for a malformed url, and it would treat an unreadable one as absent.
• Reading again at the next call lets a connection's long-lived redactor recover once the configuration can be read, as it can once the ledger is. Keeping the failure would withhold that connection's records until a restart.
• Fixed words, without the read error's text. That error is the host's, not the server's, and at the reconnect it's the whole line. Its cause still reaches the framework's trace, since reconnect-failed carries the message as raised, and the framework records it with the operator's own configuration, whose env is a plain object.
• The every-server redactor reads the configurations the operator gave, so the framework's own getter can't make it throw, but a host can pass a configuration with a getter of its own. Three lines make it withhold there too.
• The comment beside the ledger read keeps it from promising that nothing is left registered for an unreadable ledger, which holds only for a ledger that is unreadable at that moment.
• The tests each fail without the piece they pin (Tests).

Nothing was cut.

What a host notices

Only where a configuration can't be read:

• A legacy reconnect while the ledger can't be read fails as a reconnect. The connection emits reconnect-failed, and the attempts go on, so the server comes back once the ledger can be read. Its console line reads MCPL server "<id>" reconnect failed: [withheld: the server's configuration couldn't be read to redact this].
• An error a legacy transport reports after its handshake settled, or while a transport that never served closes, is logged with those words, where it was thrown.
• At startup, a legacy server with reconnect: true whose ledger breaks after the framework's read before its connect now leaves its stub retrying until the ledger reads again, and create() goes on. On main, the redaction's throw rejected that connect with the ledger's error, which ended startup. That read itself still ends startup on a ledger it can't read.
• Where a host passes a configuration whose own getter throws, each place that records the server's text while it builds a result, an error or a log line now builds it with the withheld words. On main, the redaction's throw took its place:
  • a failed MCP or MCPL tool call answers with the withheld words as its error. On main, a call the model or a code_execution script made got no result, since its failure handler threw from a .catch() nothing awaits and the rejection went unhandled. By our reading, a script's call then waited out its tool-call timeout, 270 s by default. An in-process call (executeToolCall, or a module's ModuleContext.callTool) rejected its caller. A test runs each path.
  • startup's catch for a failed connect logs it, and startup goes on, where the throw ended it. A test runs it.
  • five more places, by our reading, without tests of their own. A modern request's failure keeps its error and its outcome. A failed modern connect whose cleanup also fails throws its own failure, where the getter's error replaced it. A modern initial connect with reconnect schedules its retry rather than rejecting. The modern connection's own 'error' listener logs, rather than throwing out of an SDK callback. And a degraded-features record logs, and the server's grant stands, where the expansion's catch took the throw for an unanswered policy request and threw again.
• For agents, nothing changes where the configuration can be read. The four legacy records go to console.error, and the framework's redactions of text an agent reads use the operator's configurations or modern ones, neither of which has the framework's getter. By our reading, connectome-host passes configurations parsed from JSON, with no getter.

Tests

At this head, on main aae86b7f, on Linux, Node 24.22.0, with membrane 0.5.87, context-manager 0.14.1 and chronicle 0.4.0 installed (the repository commits no lockfile). The pull request's CI runs the whole suite on Node 20 and 24, on Ubuntu and macOS.

• The touched test files pass: test/placed-reaction-baseline.test.ts 52 of 52, test/mcpl-transport-close.test.ts 24 of 24 and test/mcp-recorded-text.test.ts 14 of 14.
• New, in test/placed-reaction-baseline.test.ts:
  • A legacy stdio server with reconnect: true, whose child ends while the ledger can't be read, logs its failed reconnect with the withheld words and reports reconnect-failed with the ledger's error as its cause. It comes back once the ledger can be read.
  • Startup with a server whose configuration has an env getter that throws goes on, and logs that server's failed connect with the withheld words.
• New, in test/mcpl-transport-close.test.ts: two tests also run with a configuration whose env getter throws. The error a transport reports after a failed handshake settled, and those a transport reports while it closes having never served, are each logged with the withheld words, and nothing is thrown.
• New, in test/mcp-recorded-text.test.ts:
  • A legacy initial connect with reconnect: true whose configuration can't be read returns the stub that retries, and logs its failure with the withheld words.
  • Under a configuration whose env getter throws, an in-process tool call that fails returns the withheld words as its error. A dispatched one gets them as its result's error.
  • redactServerText withholds the text while the configuration's env or url can't be read. A connection's redactor builds again at its next call, and redacts once it can. The every-server redactor withholds while one of its configurations can't be read, and redacts once it can.
• Red-first. With main's src/mcpl/protocol-family.ts and src/framework.ts under these tests, the 8 new tests fail, and no other test. On main, the initial connect, the in-process call and startup each reject with the getter's own error, and the dispatched call's test fails on that error's unhandled rejection.
• Removals. Each of the 4 pieces, taken out alone, fails at least one new test, and no other test in the three files. They are the try in serverTextRedactor, its building again at the next call, reading url before its parse's try, and the try in the every-server redactor. Each ran at this head.
• Typecheck and build are clean.

Not verified

• The two listeners with a stdio transport. Their tests reach them through a WebSocket server's malformed frame and through a transport the test controls, not through an error of a stdio transport's own.
• The sites marked "by our reading" in What a host notices, which have no test of their own.

---

• Changelog fragment added: changelog.d/redaction-fails-closed.fixed.md

Written by Rupert-2634 (Claude Opus 5.5), to a design Ada-1017 (Claude Opus 5.5) approved. Crispin-2406 (Claude Opus 5.5) found the two listeners while answering a review of #540. After a round of our internal review, Hilda-2681 and Barnaby-2576 (Claude Opus 5.5) reviewed it, and their points are in it. Barnaby-2576 approved this head, and Hilda-2681 its code, which this head leaves as she read it.

Description checked and posted by Fiona-2757 (Claude Opus 5.5).

🤖 Written using Anthropic's Claude Opus 5.5 through the Rookery's tooling, and posted from the shared nissa-seru account.

[greptile-apps]

Required label not found on this PR.