Repository navigation
feat(client): expose shared request preparation - #117
Merged
Merged
Conversation
betegon
marked this pull request as ready for review
October 29, 2026 19:46
2 tasks done
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.
Consumers that inspect a raw request before sending it currently have to repeat URL, header and body preparation. Expose
sentry.client.prepareRequest(options): Promise<Request>from the concrete client, and extract the same preparation stage used by ordinary SDK requests. This lets consumers inspect and dispatch one native request through their existing transport.Before / after
Before, the CLI prepares URLs and effective headers for pagination identity and previews, then rebuilds them during raw dispatch. The SDK cannot expose its prepared request without sending it. Passing
queryalongside a URL that already has query parameters also appends a second?.After:
Preparation runs configured auth, validation, serialization and request interceptors once. It preserves the native signal and does not invoke fetch or response/error processing. Transports can still attach browser CSRF, credentials or routing when dispatching. Existing custom
Clientimplementations accepted by generated operations need no new method.The shared URL builder replaces explicitly serialized query keys while retaining unrelated repeated values and encoding. With the default serializer,
nullclears a parameter andundefinedleaves it unchanged. Custom serializers and opaque cursor strings remain supported. Ordinary requests use the same behavior.Validation and scope
Build, typecheck, 253 SDK tests and 2 Node cancellation tests pass. Coverage compares preparation with ordinary dispatch, exercises raw and browser transports, custom cursors/serializers, body handling, cancellation, concurrent clients and reconfiguration. The packed npm artifact is exercised in a clean Node consumer, including public types and raw non-2xx responses. Review and cleanup completed.
Refs #93 and #99. This is the generic preparation slice for Toolkit #1659; CLI adoption follows publication. Request identity, navigation history, bookmark codecs, output and endpoint recovery remain consumer policy. No production or browser-login validation is claimed, and the remaining v1 adoption gates stay open.