I'm not sure if this would fully answer your question, but please allow me to share my knowledge which might help.

Since the tool you built human_assistance contains a human intervention, it is not recommended to invoke the graph with a tool message contains the user_input. This is incorrect. You need to catch if the state of the graph contains next or not (next indicates that the graph has a pending node waiting to resume. This typically happens when a node (like human_assistance) pauses the flow for manual input or a decision.). If it exists, this indicates that the graph got interrupted, so you need to use Command(resume=...) in graph.stream. Otherwise you pass the human message as you are doing in the code you shared.

modify your code to meet the following:

def stream_graph_updates(user_input: str):
    state = graph.get_state()
    if state.next:
        graph_input = Command(resume=user_input)
    else:
        graph_input = {"messages": [{"role": "user", "content": user_input}]}
    for event in graph.stream(graph_input, config):
        for value in event.values():
            print("Assistant:", value["messages"][-1].content)

More explanation:

When you call graph.get_state(config), LangGraph returns an object representing the current checkpointed state of your graph like where the conversation or workflow last stopped.

That state includes: The stored messages (previous inputs/outputs), the current node name (where the graph stopped), and the next step to be run.

If state.next is not None, it means that the graph execution was paused or interrupted. On the other hand, if state.next is None, it means that the graph finished normally, and you can start a new run.

So, checking if state.next: lets you distinguish between:

Resuming a previously paused graph, or starting a new conversation or graph run.

Hope I helped.

I'm an engineer on the LangChain team, and what follows is a copy & paste of my response to the same question posed as a GitHub issue on the LangGraphJS repository.

I haven't executed your code, but I think that the issue could be that on refusal you're not inserting a ToolMessage into the messages state. There are some docs on this here

You can handle this on refusal by returning a command with an update: field that has a tool message. For example:

async function approveNode (state) {
  console.log('===APPROVE NODE===');
  const lastMsg = state.messages.at(-1);
  const toolCall = lastMsg.tool_calls.at(-1);

  const interruptMessage = `Please review the following tool invocation:
${toolCall.name} with inputs ${JSON.stringify(toolCall.args, undefined, 2)}
Do you approve (y/N)`;

  console.log('=INTERRUPT PRE=');
  const interruptResponse = interrupt(interruptMessage);
  console.log('=INTERRUPT POST=');

  const isApproved = (interruptResponse.trim().charAt(0).toLowerCase() === 'y');
  if (isApproved) {
      return new Command({ goto: 'tools' });
  }

  // rejection case
  return new Command({
    goto: END,
    update: {
      messages: [
        new ToolMessage({
          status: "error"
          content: `The user declined your request to execute the ${toolCall.name} tool, with arguments ${JSON.stringify(toolCall.args)}`,
          tool_call_id: toolCall.id
        }]
    });
}

Also bear in mind that this implementation is not handling parallel tool calls. To handle parallel tool calls you have a few options.

• Decline to process all tool calls if the user disallows any tool call
  • You'll need to add one rejection ToolMessage per tool call, as shown above
  • In this model you might as well also only call interrupt once for the whole batch of calls
• Allow approved calls to proceed without running denied calls:
  • Two ways to do this:
  • Option 1: Process all of the interrupts/approvals in a loop and return a Command that routes to tools if any calls are approved (or END if no calls are approved)
    • To prevent the declined calls from processing, you'll want to use a Send object in the goto field and send a copy of the AIMessage with the tool calls filtered down to just the approved list.
    • You'll still need the array of ToolMessage in the update field of the command as above - one for each declined call.
  • Option 2: Use an array of Send in your conditional edge to fan out the tool calls to the tools node (by sending a filtered copy of the AIMessage, as mentioned above) and do the interrupt in the tool handler.
    • Without Send here you would wind up processing all tool messages in the same node, which would cause the approved tool calls to be reprocessed every time the graph is interrupted after that particular tool call is approved.

Here's a hastily-written example of how you could write a wrapper that requires approval for individual tool handlers for use with the "Option 2" approach mentioned in the last bullet above:

function requiresApproval<ToolHandlerT extends (...args: unknown[]) => unknown>(toolHandler: toolHandlerT) {
  return (...args: unknown[]) => {
    const interruptMessage = `Please review the following tool invocation: ${toolHandler.name}(${args.map(JSON.stringify).join", "})`;
    const interruptResponse = interrupt(interruptMessage);
    const isApproved = (interruptResponse.trim().charAt(0).toLowerCase() === 'y');
    if (isApproved) {
      return toolHandler(..args);
    }
    throw new Error(`The user declined your request to execute the ${toolHandler.name} tool, with arguments ${JSON.stringify(args)}`);
  }
}