Repository navigation
fix: carry CliError details across the session host RPC - #313
Conversation
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. 👍 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
@codex review |
|
Codex Review: Didn't find any major issues. You're on a roll. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Why
The operator wants every valid finding shipped now. The verifiers of #287 and #301 found that a
CliErrorfrom the session host loses itsdetailson the way to the CLI. The host RPC sent onlycodeandmessage. So a livesnapshotorscreenshotprinted"details": {}, while the same error offline haddetails.path(and, with #301,details.errno).What changed
src/protocol/messages.ts:RpcErrorSchemaallows an optionaldetailsrecord. It stays.strict().src/host/rpcServer.ts: an error response for aCliErrorcarries itsdetailswhen it has any. It leaves them out when they do not serialize to JSON (aBigIntor a circular object) or take more than 65,536 characters, and keeps the code and message (verifier findings F1 and F2). An error that is not aCliErrorstill becomesRPC_ERRORwithout details.src/host/rpcClient.ts:sendRpcrebuilds theCliErrorwith the response'sdetails.src/protocol/README.mdandsrc/host/README.md.Behavior changes for CLI and JSON users
details. For example,snapshot/screenshoton a running session whoseartifactspath is a file givedetails: { path }instead of{}. The envelope shape and the error codes do not change:detailswas already there, and it now gets filled.codeandmessage.snapshotwith a 4 KB artifact manifest of 1,000 empty entries gave exit 9RPC_ERROR"RPC response exceeds maximum buffer size." instead of exit 8MANIFEST_VALIDATION_ERROR, and aBigIntor circular value made the host crash.Compatibility
details: {}as beforedetailsfilledRPC_ERROR"RPC response failed schema validation.",retryable: true, but retrying does not helpThe last row is a downgrade: an older CLI on a session that a newer agent-tty started. Every RPC schema is
.strict()on both sides, so any added field breaks that pairing. Successes and errors without details still work there. The per-session host is an internal implementation detail, and the repo supports upgrades, not downgrades, for running sessions (for example the socket-path fallback in #288).src/protocol/README.mdstates the limit.Verification
RpcServertosendRpcround trip intest/unit/host/rpcServer.test.tsand the live case intest/integration/screenshot-out.test.tsfail on main withdetails: {}. Then 2b79858: details over 1 MiB fail with "RPC response exceeds maximum buffer size.", and aBigIntor circular value makes the server throw (an unhandled rejection), on bb7d8ff.snapshotwith the 1,000-entry manifest exits 8MANIFEST_VALIDATION_ERRORwithdetails: {}.vitest run test/unit: 1942 passed.vitest run --maxWorkers=1 --retry=2onscreenshot-out,host-renderer-rpc,empty-session-captureandbatch: 37 passed.npm run typecheck,npm run lint,npm run format:checkpass.snapshotwith a file atartifacts: the results match the table above.Refs #255
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:xhigh