langchain-ai/langgraphjs
1
0
Fork 0
mirror of https://github.com/langchain-ai/langgraphjs.git synced 2026-07-22 00:55:26 -04:00
Code Issues 108 Packages Projects Releases 20 Wiki Activity

handleChainError firing for subgraph interrupt / parent command #223

New Issue
Closed
opened 2026-02-15 17:17:32 -05:00 by yindo · 2 comments
yindo commented 2026-02-15 17:17:32 -05:00
Owner
Copy Link
Copy Source

Originally created by @cwoolum on GitHub (Apr 4, 2025).

I am seeing handleChainError fire in my callbacks. The type of the error is always ParentCommand though rather than an actual error and it doesn't appear that an error has actually occurred. Is there some additional filtering I should be doing here? What kinds of errors should I actually be expecting here?

{
  lc_error_code: undefined,
  command: {
    lg_name: "Command",
    lc_direct_tool_output: true,
    graph: "__parent__",
    update: {
      messages: [
        {
          lc_serializable: true,
          lc_kwargs: {
            content: "System message",
            additional_kwargs: {
            },
            response_metadata: {
            },
            id: "00bd808e-a0db-4ad6-b38f-8b522861379c",
          },
          lc_namespace: [
            "langchain_core",
            "messages",
          ],
          content: "System message",
          name: undefined,
          additional_kwargs: {
          },
          response_metadata: {
          },
          id: "00bd808e-a0db-4ad6-b38f-8b522861379c",
        },
        {
          lc_serializable: true,
          lc_kwargs: {
            content: "User Message",
            additional_kwargs: {
            },
            response_metadata: {
            },
            id: "7fa4d303-bc9a-458c-a991-03fad2c062c7",
          },
          lc_namespace: [
            "langchain_core",
            "messages",
          ],
          content: "User message",
          name: undefined,
          additional_kwargs: {
          },
          response_metadata: {
          },
          id: "7fa4d303-bc9a-458c-a991-03fad2c062c7",
        },
        {
          lc_serializable: true,
          lc_kwargs: {
            content: [
              {
                type: "text",
                text: "Some LLM text.",
              },
            ],
            tool_calls: [
              {
                id: "tooluse_5QLM_6dXT261xNR62_xbAw",
                name: "transfer_to_party_planner_expert",
                args: {
                },
                type: "tool_call",
              },
            ],
            response_metadata: {
              $metadata: {
                httpStatusCode: 200,
                requestId: "a4e5842c-a197-4fb5-b54f-649cd6b1fec7",
                extendedRequestId: undefined,
                cfId: undefined,
                attempts: 1,
                totalRetryDelay: 0,
              },
              metrics: {
                latencyMs: 7023,
              },
              stopReason: "tool_use",
              usage: {
                inputTokens: 1824,
                outputTokens: 233,
                totalTokens: 2057,
              },
            },
            usage_metadata: {
              input_tokens: 1824,
              output_tokens: 233,
              total_tokens: 2057,
            },
            id: "a4e5842c-a197-4fb5-b54f-649cd6b1fec7",
            invalid_tool_calls: [
            ],
            additional_kwargs: {
            },
          },
          lc_namespace: [
            "langchain_core",
            "messages",
          ],
          content: [
            {
              type: "text",
              text: "Some response text from the llm",
            },
          ],
          name: "supervisor",
          additional_kwargs: {
          },
          response_metadata: {
            $metadata: {
              httpStatusCode: 200,
              requestId: "a4e5842c-a197-4fb5-b54f-649cd6b1fec7",
              extendedRequestId: undefined,
              cfId: undefined,
              attempts: 1,
              totalRetryDelay: 0,
            },
            metrics: {
              latencyMs: 7023,
            },
            stopReason: "tool_use",
            usage: {
              inputTokens: 1824,
              outputTokens: 233,
              totalTokens: 2057,
            },
          },
          id: "a4e5842c-a197-4fb5-b54f-649cd6b1fec7",
          tool_calls: [
            {
              id: "tooluse_5QLM_6dXT261xNR62_xbAw",
              name: "transfer_to_party_planner_expert",
              args: {
              },
              type: "tool_call",
            },
          ],
          invalid_tool_calls: [
          ],
          usage_metadata: {
            input_tokens: 1824,
            output_tokens: 233,
            total_tokens: 2057,
          },
        },
        {
          lc_serializable: true,
          lc_kwargs: {
            content: "Successfully transferred to party_planner_expert",
            name: "transfer_to_party_planner_expert",
            tool_call_id: "tooluse_5QLM_6dXT261xNR62_xbAw",
            additional_kwargs: {
            },
            response_metadata: {
            },
          },
          lc_namespace: [
            "langchain_core",
            "messages",
          ],
          content: "Successfully transferred to party_planner_expert",
          name: "transfer_to_party_planner_expert",
          additional_kwargs: {
          },
          response_metadata: {
          },
          id: undefined,
          lc_direct_tool_output: true,
          status: undefined,
          tool_call_id: "tooluse_5QLM_6dXT261xNR62_xbAw",
          artifact: undefined,
        },
      ],
    },
    resume: undefined,
    goto: [
      "party_planner_expert",
    ],
  },
  name: "ParentCommand",
}
Originally created by @cwoolum on GitHub (Apr 4, 2025). I am seeing `handleChainError` fire in my callbacks. The type of the error is always `ParentCommand` though rather than an actual error and it doesn't appear that an error has actually occurred. Is there some additional filtering I should be doing here? What kinds of errors should I actually be expecting here? ``` { lc_error_code: undefined, command: { lg_name: "Command", lc_direct_tool_output: true, graph: "__parent__", update: { messages: [ { lc_serializable: true, lc_kwargs: { content: "System message", additional_kwargs: { }, response_metadata: { }, id: "00bd808e-a0db-4ad6-b38f-8b522861379c", }, lc_namespace: [ "langchain_core", "messages", ], content: "System message", name: undefined, additional_kwargs: { }, response_metadata: { }, id: "00bd808e-a0db-4ad6-b38f-8b522861379c", }, { lc_serializable: true, lc_kwargs: { content: "User Message", additional_kwargs: { }, response_metadata: { }, id: "7fa4d303-bc9a-458c-a991-03fad2c062c7", }, lc_namespace: [ "langchain_core", "messages", ], content: "User message", name: undefined, additional_kwargs: { }, response_metadata: { }, id: "7fa4d303-bc9a-458c-a991-03fad2c062c7", }, { lc_serializable: true, lc_kwargs: { content: [ { type: "text", text: "Some LLM text.", }, ], tool_calls: [ { id: "tooluse_5QLM_6dXT261xNR62_xbAw", name: "transfer_to_party_planner_expert", args: { }, type: "tool_call", }, ], response_metadata: { $metadata: { httpStatusCode: 200, requestId: "a4e5842c-a197-4fb5-b54f-649cd6b1fec7", extendedRequestId: undefined, cfId: undefined, attempts: 1, totalRetryDelay: 0, }, metrics: { latencyMs: 7023, }, stopReason: "tool_use", usage: { inputTokens: 1824, outputTokens: 233, totalTokens: 2057, }, }, usage_metadata: { input_tokens: 1824, output_tokens: 233, total_tokens: 2057, }, id: "a4e5842c-a197-4fb5-b54f-649cd6b1fec7", invalid_tool_calls: [ ], additional_kwargs: { }, }, lc_namespace: [ "langchain_core", "messages", ], content: [ { type: "text", text: "Some response text from the llm", }, ], name: "supervisor", additional_kwargs: { }, response_metadata: { $metadata: { httpStatusCode: 200, requestId: "a4e5842c-a197-4fb5-b54f-649cd6b1fec7", extendedRequestId: undefined, cfId: undefined, attempts: 1, totalRetryDelay: 0, }, metrics: { latencyMs: 7023, }, stopReason: "tool_use", usage: { inputTokens: 1824, outputTokens: 233, totalTokens: 2057, }, }, id: "a4e5842c-a197-4fb5-b54f-649cd6b1fec7", tool_calls: [ { id: "tooluse_5QLM_6dXT261xNR62_xbAw", name: "transfer_to_party_planner_expert", args: { }, type: "tool_call", }, ], invalid_tool_calls: [ ], usage_metadata: { input_tokens: 1824, output_tokens: 233, total_tokens: 2057, }, }, { lc_serializable: true, lc_kwargs: { content: "Successfully transferred to party_planner_expert", name: "transfer_to_party_planner_expert", tool_call_id: "tooluse_5QLM_6dXT261xNR62_xbAw", additional_kwargs: { }, response_metadata: { }, }, lc_namespace: [ "langchain_core", "messages", ], content: "Successfully transferred to party_planner_expert", name: "transfer_to_party_planner_expert", additional_kwargs: { }, response_metadata: { }, id: undefined, lc_direct_tool_output: true, status: undefined, tool_call_id: "tooluse_5QLM_6dXT261xNR62_xbAw", artifact: undefined, }, ], }, resume: undefined, goto: [ "party_planner_expert", ], }, name: "ParentCommand", } ```
yindo added the bug label 2026-02-15 17:17:32 -05:00
yindo closed this issue 2026-02-15 17:17:32 -05:00
yindo commented 2026-02-15 17:17:34 -05:00
Author
Owner
Copy Link
Copy Source

@benjamincburns commented on GitHub (Apr 28, 2025):

This is likely a bug. We throw and catch ParentCommand internally when Command.PARENT is returned on a node in a subgraph. We likely should be excluding it from the handleChainError callback, as it's not an erroneous termination.

@benjamincburns commented on GitHub (Apr 28, 2025): This is likely a bug. We throw and catch `ParentCommand` internally when `Command.PARENT` is returned on a node in a subgraph. We likely should be excluding it from the `handleChainError` callback, as it's not an erroneous termination.
yindo commented 2026-02-15 17:17:34 -05:00
Author
Owner
Copy Link
Copy Source

@dqbd commented on GitHub (Sep 11, 2025):

Hello! This is by design as that's the only suitable LangChain callback we can call when interrupting a graph. If you want to filter out these errors, you can do something similar to this:

graph.withConfig({
    callbacks: [
      {
        handleChainError: (error) => {
          if (error.is_bubble_up) console.log("GraphInterrupt");
        },
      },
    ],
  });
@dqbd commented on GitHub (Sep 11, 2025): Hello! This is by design as that's the only suitable LangChain callback we can call when interrupting a graph. If you want to filter out these errors, you can do something similar to this: ```typescript graph.withConfig({ callbacks: [ { handleChainError: (error) => { if (error.is_bubble_up) console.log("GraphInterrupt"); }, }, ], }); ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
checkpointer
docs-needed
documentation
enhancement
good first issue
good writeup
help wanted
invalid
langgraph-supervisor
open-swe-auto
platform
prebuilt
pull-request
Mirrored from GitHub Pull Request
 question
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langchain-ai/langgraphjs#223
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?