Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected Behavior: Parallel Execution of Asymmetric Graph #765

Open
jasontjahjono opened this issue Dec 30, 2024 · 1 comment
Open

Unexpected Behavior: Parallel Execution of Asymmetric Graph #765

jasontjahjono opened this issue Dec 30, 2024 · 1 comment

Comments

@jasontjahjono
Copy link

jasontjahjono commented Dec 30, 2024

I have this graph:

   B -----
 /         \
A           E 
 \         /
   C --- D

where B takes 5 seconds to run, C takes 2 seconds, and D takes 2 seconds. (i used timeout inside the nodes)
I expect the graph to run in 5 seconds, because I thought C and D can run in parallel while B is running (2+2 < 5 seconds).

However, in practice, it takes 7 seconds. B and C runs in parallel, but C waits for B to finish before moving into D.

Here's how I built the graph:

const workflow = new StateGraph(GraphState)
  .addNode('A', nodeA)
  .addNode('B', nodeB)
  .addNode('C', nodeC)
  .addNode('D', nodeD)
  .addNode('E', nodeE)
  .addEdge(START, 'A')
  .addEdge('A', 'B')
  .addEdge('A', 'C')
  .addEdge('C', 'D')
  .addEdge(['B', 'D'], 'E')
  .addEdge('E', END);

Here's the result:

NODE: In Node A (6ms elapsed)
NODE: In Node B (8ms elapsed)
NODE: In Node C (8ms elapsed)
NODE: In Node D (5016ms elapsed)
NODE: In Node E (7023ms elapsed)
RESULT { messages: [ 'A', 'B', 'C', 'D', 'E' ], startTime: 1735541316193 }

How do I make sure D does not wait for B to finish? I assumed this could be solved using subgraphs but I want to check if there's a more elegant solution than building a subgraph.

@jacoblee93
Copy link
Collaborator

jacoblee93 commented Jan 2, 2025

Hey @jasontjahjono, I believe we need #720 to land - you could then return a Send from node C.

Otherwise I don't think there's currently a way to get around the fact that nodes are processed one step at a time.

For now, subgraph is the best way to go. Will leave this open.

CC @nfcampos in case I'm missing something

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants