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

LangGraph throws an error when adding edges that don't exist, but that makes writing the code a bit messy #14

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

Originally created by @davidfant on GitHub (Mar 19, 2024).

Here LangGraph throws an error when trying to add an edge between nodes that don't exist:
https://github.com/langchain-ai/langgraphjs/blob/56d3d28f45748ee4254a3e658d4f0db450a8d64d/langgraph/src/graph/graph.ts#L90-L95

That makes sense but it makes my code that constructs the graph a bit confusing to read. This isn't the case for addConditionalEdge (unless providing a mapping).

Example for how I ideally want to set up the graph

agent.addNode("first", ...);
agent.addEdge("first", "second");

agent.addNode("second", ...);

Counter point: why can't I set up edges after all nodes. I can, but if a graph gets big, it's annoying and confusing to have to scroll a lot to figure out how everything is connected. I want to read the logic/paths from top to bottom, rather than just nodes and then just edges. Maybe this is just me and no one else having this problem.

What are your thoughts reg moving this validation to the compile step instead?

Originally created by @davidfant on GitHub (Mar 19, 2024). Here LangGraph throws an error when trying to add an edge between nodes that don't exist: https://github.com/langchain-ai/langgraphjs/blob/56d3d28f45748ee4254a3e658d4f0db450a8d64d/langgraph/src/graph/graph.ts#L90-L95 That **makes sense** but it makes my code that constructs the graph a bit confusing to read. This isn't the case for addConditionalEdge (unless providing a mapping). Example for how I ideally want to set up the graph ```ts agent.addNode("first", ...); agent.addEdge("first", "second"); agent.addNode("second", ...); ``` Counter point: why can't I set up edges after all nodes. I can, but if a graph gets big, it's annoying and confusing to have to scroll a lot to figure out how everything is connected. I want to read the logic/paths from top to bottom, rather than just nodes and then just edges. Maybe this is just me and no one else having this problem. What are your thoughts reg moving this validation to the compile step instead?
yindo closed this issue 2026-02-15 17:05:18 -05:00
yindo commented 2026-02-15 17:05:19 -05:00
Author
Owner
Copy Link
Copy Source

@jacoblee93 commented on GitHub (Mar 20, 2024):

@nfcampos to weigh in!

@jacoblee93 commented on GitHub (Mar 20, 2024): @nfcampos to weigh in!
yindo commented 2026-02-15 17:05:19 -05:00
Author
Owner
Copy Link
Copy Source

@nfcampos commented on GitHub (May 10, 2024):

@davidfant see improved typings added in #128 which would potentially make what you want harder? That said I'll be moving the runtime validation itself to compile() to allow you to build graphs "out of order" if you opt out of the static validation

@nfcampos commented on GitHub (May 10, 2024): @davidfant see improved typings added in #128 which would potentially make what you want harder? That said I'll be moving the runtime validation itself to compile() to allow you to build graphs "out of order" if you opt out of the static validation
yindo commented 2026-02-15 17:05:19 -05:00
Author
Owner
Copy Link
Copy Source

@andrewnguonly commented on GitHub (May 10, 2024):

What are your thoughts reg moving this validation to the compile step instead?

@jacoblee93, what's your opinion?

I'm slightly against this, but I don't know why and I don't have a strong reason. Pushing business logic validation to a compile/static check does not seem desirable IMHO if it's at the expense of increased developer maintenance. The implementation may get more complex when supporting more complicated graph features (dynamic graphs).

I think a better solution would be to allow the developer to add nodes and edges in any order (i.e. just aggregate them in a list). Then build the graph internally in topological sorted order.

@andrewnguonly commented on GitHub (May 10, 2024): > What are your thoughts reg moving this validation to the compile step instead? @jacoblee93, what's your opinion? I'm slightly against this, but I don't know why and I don't have a strong reason. Pushing business logic validation to a compile/static check does not seem desirable IMHO if it's at the expense of increased developer maintenance. The implementation may get more complex when supporting more complicated graph features (dynamic graphs). I think a better solution would be to allow the developer to add nodes and edges in any order (i.e. just aggregate them in a list). Then build the graph internally in topological sorted order.
yindo commented 2026-02-15 17:05:20 -05:00
Author
Owner
Copy Link
Copy Source

@hinthornw commented on GitHub (May 17, 2024):

It could be nice to have something where it creates the node and adds an edge at the same time (for simple edges), like node.to(other_node), however.

@hinthornw commented on GitHub (May 17, 2024): It could be nice to have something where it creates the node and adds an edge at the same time (for simple edges), like `node.to(other_node)`, however.
yindo commented 2026-02-15 17:05:20 -05:00
Author
Owner
Copy Link
Copy Source

@jacoblee93 commented on GitHub (May 17, 2024):

Hey sorry for missing the ping!

@andrewnguonly I don't feel super strongly but adjacency lists are a common way to declare graphs in general which naturally imply declaring edges before declaring all nodes:

1: 2, 3
2: 1
3: 1

It does increase the likelihood of something being misrouted if a name changes, but I lean towards @davidfant's comments here around convenience.

@jacoblee93 commented on GitHub (May 17, 2024): Hey sorry for missing the ping! @andrewnguonly I don't feel super strongly but adjacency lists are a common way to declare graphs in general which naturally imply declaring edges before declaring all nodes: ```ts 1: 2, 3 2: 1 3: 1 ``` It does increase the likelihood of something being misrouted if a name changes, but I lean towards @davidfant's comments here around convenience.
yindo commented 2026-02-15 17:05:20 -05:00
Author
Owner
Copy Link
Copy Source

@dqbd commented on GitHub (Jun 17, 2025):

Should be already solved!

@dqbd commented on GitHub (Jun 17, 2025): Should be already solved!
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
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#14
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?