fix(workflow): allow dual-mode blocks inside loop/parallel subflows - #6633

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Aug 12, 2026 6:29pm

PR Summary

Low Risk
Single guard condition in canvas drop handling; behavior aligns with existing trigger checks elsewhere with no auth or data changes.

Overview
Fixes a false positive when dropping blocks into loop or parallel subflows via the toolbar or connection picker: dual-mode integrations (e.g. Gmail, Slack) were blocked with “Triggers cannot be placed inside loop or parallel subflows” even when added as normal action blocks.

In handleToolbarDrop, the subflow guard no longer treats blockConfig.triggers?.enabled as “this drop is a trigger.” It only rejects pure trigger blocks (category === 'triggers') and drops with enableTriggerMode === true, matching TriggerUtils.isTriggerBlock and the drag/paste paths that use actual trigger mode state.

^{Reviewed by Cursor Bugbot for commit 508ebe3. Bugbot is set up for automated code reviews on this repo. Configure here.}

Greptile Summary

This PR corrects subflow block insertion by distinguishing trigger capability from actual trigger mode.

• Allows dual-mode integration blocks to be added as ordinary blocks inside loop and parallel subflows.
• Continues rejecting pure trigger blocks and dual-mode blocks explicitly dropped in trigger mode.

Confidence Score: 5/5

The PR appears safe to merge with no actionable defects identified in the changed trigger-placement guard.

Current insertion paths preserve explicit trigger mode when selecting a block as a trigger, while ordinary dual-mode selections are initialized without trigger mode as intended.

_{Reviews (1): Last reviewed commit: "fix(workflow): allow dual-mode blocks in..." | Re-trigger Greptile}