improvement(executor): support nested loops/parallels

[waleedlatif1]

Summary

• Fix z-index bug preventing clicks on inner subflows when outer is selected
• Fix nested parallel execution ("Parallel start not connected") by adding sentinel-based boundary resolution
• Extract shared iteration context utilities, remove duplicated code across block-executor and workflow-handler
• Add cycle guards to buildParentIterations, getNodeHierarchy, and isLoopNestedInside
• Replace paste subflow blanket-block with cycle-only prevention
• Use recursive helpers in terminal instead of hardcoded 2-level depth checks
• Remove aliased imports, dead code, unused parameters, and tighten any types to unknown
• Add edge construction tests for nested parallel and parallel-in-loop wiring

Fixes #3301

Type of Change

• Bug fix
• Improvement

Testing

• All 601 executor tests pass
• Clean type-check
• Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 4, 2026 3:01am

[greptile-apps]

Greptile Summary

This PR comprehensively implements support for nested loop/parallel execution across all four nesting combinations. The implementation is thorough with proper sentinel-based boundary resolution, subflow graph cloning, unified parent maps, and scope cleanup. All tests pass.

Verified Fixes from Prior Review Rounds:

• Cycle guards added to ancestor-chain traversals in workflow.tsx (lines 1024, 2641, 2645)
• Stale cloned loop scopes and subflowParentMap entries are now cleaned up consistently in loop.ts
• findEffectiveContainerId fallback scan removed; direct lookup only
• Sentinel edge handles correctly selected (LOOP_EXIT vs PARALLEL_EXIT) in parallel-expansion.ts
• Test coverage for loop-in-parallel wiring added to edges.test.ts

Two Remaining Findings:

1. Missing cycle guard in nestingLevel useMemo (subflow-node.tsx) — mirrors guards added elsewhere for consistency
2. Parallel-config scan in buildSubflowParentMap can silently overwrite loop-config entries — defensive logging recommended

Safe to merge with these two minor defensive hardening improvements.

Confidence Score: 4/5

• Safe to merge; core functionality is solid with comprehensive test coverage (601 executor tests pass). Two minor defensive improvements recommended.
• All major cycle-guard and cleanup issues identified in prior reviews have been addressed. The two remaining findings are minor and low-risk: (1) a missing cycle guard in a React useMemo that mirrors guards added elsewhere in the PR, and (2) an edge-case defensive improvement for invalid workflow data. The implementation is well-tested and properly handles all nesting combinations.
• apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/subflows/subflow-node.tsx (missing cycle guard), apps/sim/executor/execution/executor.ts (defensive logging for config conflicts)

_{Last reviewed commit: 2a6b631}

[greptile-apps]

_{39 files reviewed, 10 comments}

_{Edit Code Review Agent Settings | Greptile}

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[greptile-apps]

Additional Comments (1)

apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/terminal/utils.ts
Empty workflowId in synthetic iteration entries when iterBlocks is empty

When a synthetic iteration group has no direct topLevelIterationEntries (iterBlocks is empty — only strippedNestedEntries exist), iterBlocks[0]?.workflowId evaluates to undefined, so workflowId falls back to ''. Since strippedNestedEntries always has at least one entry in this branch (otherwise allIterEntries.length === 0 returns null earlier), the workflowId and executionId could be sourced from there as a fallback.

          const syntheticIteration: ConsoleEntry = {
            id: `${idPrefix}iteration-${iterationType}-${iterGroup.iterationContainerId}-${iterGroup.iterationCurrent}-${iterBlocks[0]?.executionId ?? strippedNestedEntries[0]?.executionId ?? 'unknown'}`,
            timestamp: new Date(iterStartMs).toISOString(),
            workflowId: iterBlocks[0]?.workflowId || strippedNestedEntries[0]?.workflowId || '',
            blockId: `iteration-${iterGroup.iterationContainerId}-${iterGroup.iterationCurrent}`,
            blockName: `Iteration ${iterGroup.iterationCurrent}${iterGroup.iterationTotal !== undefined ? ` / ${iterGroup.iterationTotal}` : ''}`,
            blockType: iterationType,
            executionId: iterBlocks[0]?.executionId ?? strippedNestedEntries[0]?.executionId,
            startedAt: new Date(iterStartMs).toISOString(),
            executionOrder: iterExecutionOrder,
            endedAt: new Date(iterEndMs).toISOString(),
            durationMs: iterDisplayDuration,
            success: !allIterEntries.some((b) => b.error),
            iterationCurrent: iterGroup.iterationCurrent,
            iterationTotal: iterGroup.iterationTotal,
            iterationType: iterationType as 'loop' | 'parallel',
            iterationContainerId: iterGroup.iterationContainerId,
          }

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[greptile-apps]

Additional Comments (3)

apps/sim/executor/orchestrators/parallel.ts, line 260
Removed count-type parallel guard may cause regression

The explicit if (config.parallelType === 'count') return [] guard was deleted from resolveDistributionItems. For count-type parallels, distribution is typically undefined (falling into the new early-return), but if a user switches a parallel from collection to count via the UI and the old distribution value is preserved in the serialized workflow, the new code will fall through and attempt to resolve that value as an items list.

The original guard was an intentional safety net for exactly this case — it ensured that regardless of what distribution contains, count-type parallels always produce an empty items array. Consider restoring it:

  private resolveDistributionItems(ctx: ExecutionContext, config: SerializedParallel): any[] {
    if (config.parallelType === 'count') {
      return []
    }

    if (
      config.distribution === undefined ||
      config.distribution === null ||
      config.distribution === ''
    ) {
      return []
    }

---

apps/sim/executor/utils/parallel-expansion.ts, line 320
Clone configs and nodes accumulate across loop iterations

cloneSubflowGraph registers cloned subflows in dag.parallelConfigs, dag.loopConfigs, and dag.nodes via cloneDAGNode, but none of these entries are ever removed between outer-loop iterations. Each call to expandParallel (one per loop iteration) adds (branchCount - 1) new clone configs and their associated DAG nodes, which persist for the lifetime of the execution.

For a loop with K iterations containing a parallel with N branches, this adds K × (N-1) clone entries to the DAG maps. At the configured maximums (1 000 iterations × 20 branches), that is ~19 000 accumulated entries.

A secondary effect is that collectClonedSubflowNodes (used by clearLoopExecutionState) scans all keys in dag.loopConfigs / dag.parallelConfigs for matching prefixes, so it collects stale clones from every previous iteration on each cleanup pass. state.unmarkExecuted on already-unmarked nodes is harmless, but the linear scan cost grows with each iteration.

Consider tracking which clone IDs were created by each expandParallel call (e.g., return them in ExpansionResult alongside clonedSubflows) and removing them from the DAG maps inside deleteParallelScopeAndClones / resetNestedParallelScopes.

---

apps/sim/executor/execution/executor.ts, line 275
buildSubflowParentMap parallel scan silently overwrites loop scan entries

The loop scan runs first, then the parallel scan iterates dag.parallelConfigs and calls parentMap.set(nodeId, ...) for any child that is itself a subflow. If the same child subflow ID appears as a direct child of both a loop and a parallel (e.g., a shared subflow referenced from two different containers due to data corruption or a future edge-case workflow shape), the parallel scan will silently overwrite the loop scan's entry with parentType: 'parallel'.

More importantly, even in the expected "clean" case, the ordering means parentType: 'parallel' always wins over parentType: 'loop' when both scans touch the same key. Adding a defensive check to warn when an overwrite would occur helps surface unexpected configurations:

for (const nodeId of config.nodes ?? []) {
  if (dag.parallelConfigs.has(nodeId) || dag.loopConfigs.has(nodeId)) {
    if (parentMap.has(nodeId)) {
      logger.warn('Subflow has multiple parents in buildSubflowParentMap', {
        nodeId,
        existing: parentMap.get(nodeId),
        incoming: { parentId: parallelId, parentType: 'parallel' },
      })
    }
    parentMap.set(nodeId, { parentId: parallelId, parentType: 'parallel' })
  }
}

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

[greptile-apps]

Additional Comments (2)

apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/subflows/subflow-node.tsx, line 87
Missing cycle guard in nestingLevel parent-chain traversal

The while (currentParentId) loop lacks a visited set to prevent infinite loops if the parentId chain ever forms a cycle. The PR already adds visited-set guards in several analogous loops (buildParentIterations, getNodeHierarchy, isLoopNestedInside, buildUnifiedParentIterations). The same pattern should be applied here for consistency and defensive safety:

const nestingLevel = useMemo(() => {
  let level = 0
  let currentParentId = data?.parentId
  const visited = new Set<string>()

  while (currentParentId && !visited.has(currentParentId)) {
    visited.add(currentParentId)
    level++
    const parentNode = getNodes().find((n) => n.id === currentParentId)
    if (!parentNode) break
    currentParentId = parentNode.data?.parentId
  }

  return level
}, [id, data?.parentId, getNodes])

---

apps/sim/executor/execution/executor.ts, line 399
Parallel-config scan can silently overwrite loop-config scan for the same child

buildSubflowParentMap runs the loop scan first, then the parallel scan. Because parentMap.set is unconditional, any nodeId that appears in both a loop config's nodes and a parallel config's nodes will end up with parentType: 'parallel', regardless of which scan found the correct parent.

A valid workflow guarantees each container has exactly one parent, so this normally cannot happen. However, consider an edge case: if the same nested subflow ID is accidentally registered in both a loop config and a parallel config (e.g. during a migration or a copy-paste bug in the serializer), the parallel entry silently wins and buildUnifiedParentIterations will walk the wrong ancestor chain, producing incorrect iteration context without any warning.

A defensive guard would make the conflict visible:

// Scan parallel configs: children can be parallels or loops
for (const [parallelId, config] of dag.parallelConfigs) {
  for (const nodeId of config.nodes ?? []) {
    if (dag.parallelConfigs.has(nodeId) || dag.loopConfigs.has(nodeId)) {
      if (parentMap.has(nodeId)) {
        logger.warn('Subflow registered under multiple parents — keeping loop entry', {
          nodeId,
          loopParent: parentMap.get(nodeId)?.parentId,
          parallelParent: parallelId,
        })
        continue
      }
      parentMap.set(nodeId, { parentId: parallelId, parentType: 'parallel' })
    }
  }
}