fix(triggers): update filtering logic for edges

[icecrasher321]

Summary

Need to filter all edges targetting triggers.

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			Nov 8, 2025 3:56am

[greptile-apps]

Greptile Overview

Greptile Summary

Strengthened trigger block isolation by filtering ALL incoming edges to trigger blocks (not just trigger-to-trigger edges).

Key changes:

• Updated use-block-connections.ts and workflow-execution-utils.ts to filter all incoming edges targeting trigger blocks
• Previous logic only filtered edges where both source AND target were triggers (sourceIsTrigger && targetIsTrigger)
• New logic filters any edge where the target is a trigger (targetIsTrigger), regardless of source type
• Removed unnecessary sourceIsTrigger check, simplifying the logic
• Consistent with trigger design philosophy: triggers are independent entry points and should never receive incoming connections

Rationale:
This change ensures triggers remain completely independent entry points in workflow execution graphs. Since triggers define workflow start points (manual, API, chat, webhooks, schedules), allowing any incoming edges would violate their semantic purpose and potentially create execution path ambiguities.

Confidence Score: 5/5

• This PR is safe to merge with no risk
• The change is a straightforward logic simplification that strengthens an existing invariant. It removes the unnecessary sourceIsTrigger check, making the filtering more comprehensive and correct. The change is applied consistently across both UI (use-block-connections.ts) and execution (workflow-execution-utils.ts) layers, and aligns perfectly with the semantic meaning of triggers as independent entry points.
• No files require special attention

Important Files Changed

File Analysis

Filename	Score	Overview
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/hooks/use-block-connections.ts	5/5	Updated edge filtering logic to block ALL incoming edges to trigger blocks instead of only trigger-to-trigger edges
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/lib/workflow-execution-utils.ts	5/5	Applied identical filtering logic change as use-block-connections.ts - filters all incoming edges to triggers

Sequence Diagram

sequenceDiagram
participant User
participant UI as Workflow UI
participant Hook as useBlockConnections
participant Utils as filterEdgesFromTriggerBlocks
participant TriggerUtils
participant Executor
User->>UI: View workflow with trigger blocks
UI->>Hook: Call useBlockConnections(blockId)
Hook->>Utils: Filter edges
loop For each edge
Utils->>TriggerUtils: isTriggerBlock(targetBlock)
TriggerUtils-->>Utils: Returns true/false
alt Target is trigger
Utils->>Utils: Filter out edge (return false)
else Target is not trigger
Utils->>Utils: Keep edge (return true)
end
end
Utils-->>Hook: Return filtered edges
Hook->>Hook: Calculate block connections
Hook-->>UI: Return incoming connections
User->>Executor: Execute workflow
Executor->>Utils: filterEdgesFromTriggerBlocks(blocks, edges)
Utils-->>Executor: Return filtered edges (no incoming to triggers)
Executor->>Executor: Build execution graph from filtered edges
Executor-->>User: Execute workflow starting from trigger

Loading

_{2 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}