fix: validate request parameters when the request is made - #962
Merged
Conversation
Required-parameter validation ran inside the endpoint method that builds a request, so it threw synchronously at build time rather than when the request was sent. A SeamHttpRequest is a value. Callers may build one well before deciding to send it — to derive a cache key from it, to hold it while the data it needs arrives, or to hand it somewhere else entirely. Throwing at build time makes that surprising: consumers using a data-fetching library commonly construct a request during render and gate the send on whether the id is known yet, which means a request that is deliberately not being sent yet takes down the render. Validation now happens in fetchResponse, so it reports from execute, await, then, catch and finally — every path that actually talks to the API — and a request that is never sent never raises. The checks, their order and their messages are unchanged; only the timing moves. Endpoint methods pass the parameters and their requiredness to SeamHttpRequest instead of asserting first, and the parameters are carried separately from body and params so undefined and null stay distinguishable. Note this changes an error that previously surfaced synchronously into a rejected promise. Callers asserting on a synchronous throw need to await instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VxuhZpWQMkLkdmo9LJC7kY
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.
Required-parameter validation ran inside the endpoint method that builds a
request, so it threw synchronously at build time rather than when the request
was sent.
A SeamHttpRequest is a value. Callers may build one well before deciding to
send it — to derive a cache key from it, to hold it while the data it needs
arrives, or to hand it somewhere else entirely. Throwing at build time makes
that surprising: consumers using a data-fetching library commonly construct a
request during render and gate the send on whether the id is known yet, which
means a request that is deliberately not being sent yet takes down the render.
Validation now happens in fetchResponse, so it reports from execute, await,
then, catch and finally — every path that actually talks to the API — and a
request that is never sent never raises. The checks, their order and their
messages are unchanged; only the timing moves. Endpoint methods pass the
parameters and their requiredness to SeamHttpRequest instead of asserting
first, and the parameters are carried separately from body and params so
undefined and null stay distinguishable.
Note this changes an error that previously surfaced synchronously into a
rejected promise. Callers asserting on a synchronous throw need to await
instead.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01VxuhZpWQMkLkdmo9LJC7kY