fix(sdk): always attach Response on HTTPError

[edenbuilds]

Summary

• Always pass includeResponse: true when converting failed Response objects to HTTPError, so error.response is available without registering onFailedResponseHook.

Test plan

• New unit test should attach error.response without onFailedResponseHook passes with the fix
• Same test fails with response: undefined when the fix is stashed (git stash A/B)
• Changeset for @langchain/langgraph-sdk

Fixes #2632

[changeset-bot]

🦋 Changeset detected

Latest commit: 36c64db

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 5 packages

Name	Type
@langchain/langgraph-sdk	Patch
@langchain/angular	Patch
@langchain/react	Patch
@langchain/svelte	Patch
@langchain/vue	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@langchain/langgraph-checkpoint

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-checkpoint@2668

@langchain/langgraph-checkpoint-mongodb

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-checkpoint-mongodb@2668

@langchain/langgraph-checkpoint-postgres

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-checkpoint-postgres@2668

@langchain/langgraph-checkpoint-redis

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-checkpoint-redis@2668

@langchain/langgraph-checkpoint-sqlite

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-checkpoint-sqlite@2668

@langchain/langgraph-checkpoint-validation

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-checkpoint-validation@2668

create-langgraph

npm i https://pkg.pr.new/langchain-ai/langgraphjs/create-langgraph@2668

@langchain/langgraph-api

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-api@2668

@langchain/langgraph-cli

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-cli@2668

@langchain/langgraph

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph@2668

@langchain/langgraph-cua

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-cua@2668

@langchain/langgraph-supervisor

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-supervisor@2668

@langchain/langgraph-swarm

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-swarm@2668

@langchain/langgraph-ui

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-ui@2668

@langchain/langgraph-sdk

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/langgraph-sdk@2668

@langchain/angular

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/angular@2668

@langchain/react

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/react@2668

@langchain/svelte

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/svelte@2668

@langchain/vue

npm i https://pkg.pr.new/langchain-ai/langgraphjs/@langchain/vue@2668

commit: 36c64db

[Denys Korolkov · Founder @ Routine Run (denyskorolkov)]

Matches the proposed fix in the issue (option 2 — always
attach response, decoupled from onFailedResponseHook).

Nit on the changeset: "even when onFailedResponseHook is unset" reads like the
hook is still relevant post-fix, but it plays no role anymore in whether
response gets attached - might read cleaner as just "Always attach the
underlying Response on HTTPError." (the historical coupling is useful context
in the PR description, doesn't need to be in the public changelog).

Also curious: is response still expected to be undefined in some paths
(e.g. a network failure with no Response object at all), or does this
guarantee a value now?

[edenbuilds]

Thanks Denys Korolkov · Founder @ Routine Run (@denyskorolkov) — both taken.

Changeset. You're right, the hook has no role post-fix and mentioning it in the changelog only implies otherwise. Now just:

Always attach the underlying Response on HTTPError.

The historical coupling stays in the PR description.

On response still being undefined: not for HTTPError. It's constructed in exactly one place — the isResponse(error) branch of AsyncCaller.call — so with includeResponse: true every HTTPError the SDK throws now carries its Response.

A failure with no Response never becomes an HTTPError at all, which is the case you're pointing at:

• a generic rejection hits if (error instanceof Error) throw error and is rethrown untouched;
• a network failure whose message matches the connection checks (fetch failed, ECONNREFUSED, …) is replaced, once retries are exhausted, by a plain Error with name === "ConnectionError".

Neither carries response or status, and neither did before. So the property stays optional on the class because the constructor parameter is optional, but there's no longer an HTTPError path that omits it.

I added a test pinning that boundary, since it's exactly the question a future reader will have:

it("should not attach a response to failures that carry none", async () => {
  // TypeError("boom") → rethrown as-is; TypeError("fetch failed") → ConnectionError
  expect(error).not.toHaveProperty("response");
  expect(error).not.toHaveProperty("status");
});

Writing it corrected my own assumption, incidentally — I expected fetch failed to surface as the original TypeError, and it comes back as ConnectionError because the message matches the connection branch even with maxRetries: 0.

17 caller tests pass, and the error.response regression still fails against the current async_caller.ts. Squashed to one commit.

[Denys Korolkov · Founder @ Routine Run (denyskorolkov)]

Thanks Backend & AI Systems Engineer · Founder @ Prema Vision (Denys Korolkov · Founder @ Routine Run (@denyskorolkov)) — both taken.

Changeset. You're right, the hook has no role post-fix and mentioning it in the changelog only implies otherwise. Now just:

Always attach the underlying Response on HTTPError.

The historical coupling stays in the PR description.

On response still being undefined: not for HTTPError. It's constructed in exactly one place — the isResponse(error) branch of AsyncCaller.call — so with includeResponse: true every HTTPError the SDK throws now carries its Response.

A failure with no Response never becomes an HTTPError at all, which is the case you're pointing at:

• a generic rejection hits if (error instanceof Error) throw error and is rethrown untouched;
• a network failure whose message matches the connection checks (fetch failed, ECONNREFUSED, …) is replaced, once retries are exhausted, by a plain Error with name === "ConnectionError".

Neither carries response or status, and neither did before. So the property stays optional on the class because the constructor parameter is optional, but there's no longer an HTTPError path that omits it.

I added a test pinning that boundary, since it's exactly the question a future reader will have:

it("should not attach a response to failures that carry none", async () => {
  // TypeError("boom") → rethrown as-is; TypeError("fetch failed") → ConnectionError
  expect(error).not.toHaveProperty("response");
  expect(error).not.toHaveProperty("status");
});

Writing it corrected my own assumption, incidentally — I expected fetch failed to surface as the original TypeError, and it comes back as ConnectionError because the message matches the connection branch even with maxRetries: 0.

17 caller tests pass, and the error.response regression still fails against the current async_caller.ts. Squashed to one commit.

Thanks for doing this and sharing the ConnectionError catch, glad it's pinned in a test now. Contribution looks great.

[edenbuilds]

Thanks Denys Korolkov · Founder @ Routine Run (@denyskorolkov) — appreciate the review and the green light. Happy to iterate if anything else comes up before merge.

[Christian Bromann (christian-bromann)]

Thank you , LGTM 👍