Repository navigation
fix: prevent duplicate messages and unpaired tool calls when editing a message - #335
Open
Harrison (iZiTTMarvin) wants to merge 1 commit into
Open
Harrison (iZiTTMarvin) wants to merge 1 commit into
Harrison (iZiTTMarvin) wants to merge 1 commit into
Conversation
…a message Build the edit's optimistic values from the parent checkpoint instead of the state that already contains the edited message, give the new message a uuid like the main composer, pair dangling tool calls as a normal submit does, and show an error instead of submitting when the parent checkpoint is unavailable.
|
Harrison (@iZiTTMarvin) is attempting to deploy a commit to the LangChain Team on Vercel. A member of the Team first needs to authorize it. |
This branch has not been deployed
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.
Summary
Addresses #204.
Editing a human message had two problems in
src/components/thread/messages/human.tsx:optimisticValuesstarted fromgetMessagesMetadata(message).firstSeenState.values. In@langchain/langgraph-sdk1.12.4,firstSeenStateis the oldest history state that already contains the edited message (dist/react/stream.lgp.js:271,findLast(history, state => messages.includes(messageId))), so appending the new message rendered the old and new text together until the run streamed back.ensureToolCallsHaveResponses(index.tsx), but the edit path did not. Forking from the parent checkpoint then sent[..., ai(tool_calls), human], which providers like Anthropic reject (tool_use ids were found without tool_result blocks).Changes (single file):
thread.historybycheckpoint_id), i.e. exactly what the server forks from. This does not depend on message ids.ensureToolCallsHaveResponses, same as a normal submit.uuidv4()id, like the main composer.The server-side fork itself (
submit(input, { checkpoint: parent })) was already correct, soupdateState+submit(null)is not needed.Repro (deterministic local LangGraph.js graph, no model keys)
[..., "hello", "edited"]. After:[..., "edited"]. Final server state is unchanged and tool call/result ids stay paired.tool_use ids were found without tool_result blocks immediately after: call_1(provider validation mimicked in the graph). After: the run completes.Verification
pnpm format:checkandpnpm build: pass.eslint .: 0 errors and the same 18 existing warnings asmain(on Windows, run withNODE_OPTIONSset manually because thelintscript uses POSIX env syntax).langgraphjs devwith the graph above.Limitations
tool_useerror.