Skip to content

fix: validate request parameters when the request is made - #962

Merged
razor-x merged 2 commits into
mainfrom
claude/seam-http-client-serializer-y5jof3
Aug 13, 2026
Merged

fix: validate request parameters when the request is made#962
razor-x merged 2 commits into
mainfrom
claude/seam-http-client-serializer-y5jof3

Conversation

@razor-x

@razor-x razor-x commented Aug 13, 2026

Copy link
Copy Markdown
Member

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

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
@razor-x
razor-x requested a review from a team as a code owner August 13, 2026 22:48
@razor-x
razor-x merged commit d6000b1 into main Aug 13, 2026
16 checks passed
@razor-x
razor-x deleted the claude/seam-http-client-serializer-y5jof3 branch August 13, 2026 22:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants