Repository navigation
Support public error serialization and useful HTTP failures - #13
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Applications currently have to catch every service failure themselves to prevent internal error details from reaching callers. HTTP failures can also produce an empty
RpcError.messageor discard a server's useful upload-limit explanation.Add an optional synchronous
serializeError(error, method)callback that selects the public JSON-RPC error whileonErrorretains the original failure for diagnostics. Carry it through HTTP handlers, raw sessions, and both WebSocket peers. Existing serialization remains unchanged when the option is omitted, and protocol errors retain their standard responses.For non-2xx HTTP responses, preserve an explicitly supplied JSON
{ error: string }explanation. Other responses useRequest failed (HTTP <status>).instead of relying on status text or displaying arbitrary response bodies. The error code remains the HTTP status. Documentation describes these conventions and makes clear that a failed response does not establish whether execution occurred.Upstreams the reusable parts of https://github.com/jmorrell/stacks/pull/263 and https://github.com/jmorrell/stacks/pull/264. Application-specific error classifications, telemetry, and UI recovery stay in Stacks.
Validation: all 171 tests passed, including Workers runtime coverage for serialization in both WebSocket directions, mixed HTTP batch outcomes with original diagnostics, and HTTP explanation/fallback behavior. Formatting checks and build passed. Lint passed with three pre-existing unused-import warnings in the unchanged
websocket.test.ts. Author review traced option propagation through all public transport entry points and checked default-error compatibility; no independent review was performed in this repository.Types and sequencing:
RpcHandlerOptionsgains the optional serializer;RpcSessionOptionsincludes those handler options; the WebSocket client acceptsRpcHandlerOptionsdirectly instead of its private onError-only alias. Wire response types are unchanged. On a handler failure, the existingonErrorcallback runs before the optional serializer. Both callbacks must not throw.