fix(triggers): incoming edges should be filtered from execution and UI graph

[icecrasher321]

Summary

Incoming edges for triggers should be filtered out of relevant graphs.

Type of Change

• Bug fix

Testing

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	Preview	Comments	Updated (UTC)
docs	Skipped			Oct 31, 2025 3:20am

[greptile-apps]

Greptile Overview

Greptile Summary

This PR introduces a systematic fix to filter out edges between trigger blocks across all execution and UI contexts. The implementation adds a centralized filterEdgesFromTriggerBlocks utility function that removes trigger-to-trigger edges while preserving edges from triggers to regular blocks.

Key changes:

• Created reusable filtering function in workflow-execution-utils.ts that checks both source and target blocks using TriggerUtils.isTriggerBlock
• Applied filtering consistently in 6 locations: UI rendering, block connections hook, workflow execution hook, API route, and background job execution
• Ensures triggers remain independent entry points without cross-trigger dependencies
• Maintains backward compatibility by keeping edges when blocks aren't found (graceful degradation)

Design rationale:
The fix correctly treats triggers as independent workflow entry points. By filtering trigger-to-trigger edges in both execution graphs and UI rendering, it ensures consistency between what users see and what actually executes. The implementation properly leverages the existing TriggerUtils.isTriggerBlock method which handles multiple trigger types (explicit trigger category, triggerMode flag, and legacy starter blocks).

Confidence Score: 5/5

• This PR is safe to merge with high confidence
• The implementation is well-structured with a centralized utility function applied consistently across all execution contexts. The filtering logic is straightforward and defensive (keeps edges when blocks are missing), and it properly integrates with the existing TriggerUtils infrastructure. No breaking changes or edge cases identified.
• No files require special attention

Important Files Changed

File Analysis

Filename	Score	Overview
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/lib/workflow-execution-utils.ts	5/5	Added filterEdgesFromTriggerBlocks utility function to filter trigger-to-trigger edges; applied consistently in executeWorkflowWithLogging
apps/sim/app/api/workflows/[id]/execute/route.ts	5/5	Applied edge filtering before serialization and in stream context extensions; consistent with execution logic
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/hooks/use-block-connections.ts	5/5	Filters trigger-to-trigger edges before calculating block paths; ensures UI tags show only execution-relevant connections
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/hooks/use-workflow-execution.ts	5/5	Updated to use filterEdgesFromTriggerBlocks instead of keeping all edges intact; maintains consistency with execution behavior
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/workflow.tsx	5/5	Applies edge filtering to display edges after reconstructing deleted edges in diff mode; ensures UI consistency
apps/sim/background/workflow-execution.ts	5/5	Applied edge filtering in background job execution; maintains consistent behavior across execution contexts

Sequence Diagram

sequenceDiagram
participant User
participant WorkflowUI as Workflow UI
participant ExecutionHook as useWorkflowExecution
participant APIRoute as API Execute Route
participant BGJob as Background Job
participant FilterUtil as filterEdgesFromTriggerBlocks
participant TriggerUtils as TriggerUtils.isTriggerBlock
participant Serializer
participant Executor
Note over WorkflowUI,Executor: Workflow Execution with Trigger Edge Filtering
User->>WorkflowUI: Load workflow
WorkflowUI->>FilterUtil: Filter edges for display
FilterUtil->>TriggerUtils: Check if source is trigger
FilterUtil->>TriggerUtils: Check if target is trigger
TriggerUtils-->>FilterUtil: Return trigger status
FilterUtil-->>WorkflowUI: Return filtered edges (no trigger-to-trigger)
WorkflowUI->>User: Display workflow with filtered edges
User->>ExecutionHook: Execute workflow
ExecutionHook->>FilterUtil: Filter edges before execution
FilterUtil->>TriggerUtils: Validate trigger blocks
TriggerUtils-->>FilterUtil: Trigger validation results
FilterUtil-->>ExecutionHook: Filtered edges
ExecutionHook->>Serializer: Serialize with filtered edges
Serializer-->>ExecutionHook: Serialized workflow
ExecutionHook->>Executor: Execute workflow
Executor-->>User: Execution result
User->>APIRoute: API execution request
APIRoute->>FilterUtil: Filter edges from trigger blocks
FilterUtil->>TriggerUtils: Check trigger status
TriggerUtils-->>FilterUtil: Validation complete
FilterUtil-->>APIRoute: Filtered edges
APIRoute->>Serializer: Serialize workflow
Serializer-->>APIRoute: Serialized workflow
APIRoute->>Executor: Execute with filtered edges
Executor-->>User: API response
User->>BGJob: Background job trigger
BGJob->>FilterUtil: Filter trigger-to-trigger edges
FilterUtil->>TriggerUtils: Identify trigger blocks
TriggerUtils-->>FilterUtil: Trigger identification
FilterUtil-->>BGJob: Return filtered edges
BGJob->>Serializer: Serialize with filtered graph
Serializer-->>BGJob: Serialized workflow
BGJob->>Executor: Execute in background
Executor-->>User: Job result

Loading

_{6 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}