-
Notifications
You must be signed in to change notification settings - Fork 3.2k
improvement(start-block): move away from unified start block to split triggers #1326
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Greptile Summary
This PR implements a major architectural refactoring that moves away from the monolithic starter block system to dedicated trigger blocks for different workflow execution contexts. The changes introduce four new trigger block types: ApiTriggerBlock for HTTP endpoint exposure, ChatTriggerBlock for chat interface deployment, InputTriggerBlock for manual execution with typed schemas, and WorkflowInputBlock for structured child workflow execution.
The refactoring touches multiple layers of the system:
Block System Changes: The legacy StarterBlock is simplified and hidden from the toolbar (hideFromToolbar: true), retaining only manual and chat modes for backward compatibility. New trigger blocks are registered in the block registry with proper categorization (category: 'triggers') and trigger-specific configurations.
UI Layer Enhancements: New components are introduced including TriggerSelectorModal for trigger selection, TriggerPlaceholder for empty workflows, and TriggerWarningDialog for constraint enforcement. The InputMapping component enables dynamic field mapping between parent and child workflows based on Input Trigger schemas.
Execution Engine Updates: The executor now accepts a startBlockId parameter to specify which trigger block should initiate execution, replacing the previous automatic start block detection. The TriggerUtils class provides centralized logic for trigger classification, validation, and constraint enforcement (e.g., single API trigger per workflow).
API and Database Changes: The workflow execution API (/api/workflows/[id]/execute) now determines appropriate trigger blocks using TriggerUtils.findStartBlock() and validates that API triggers have outgoing connections. New workspace creation no longer automatically adds starter blocks, instead initializing empty workflows.
Collaborative Features: The collaborative workflow system now supports triggerMode parameters for proper synchronization of trigger-specific blocks across clients. The tag dropdown system has been updated to handle dynamic outputs from the new trigger blocks using getBlockOutputPaths and getBlockOutputType helpers.
The implementation maintains full backward compatibility with existing workflows using starter blocks while enabling the new trigger architecture. Validation logic prevents mixing legacy and new trigger types, and enforces single-instance constraints for certain trigger types (e.g., only one API trigger per workflow).
Confidence score: 3/5
- This PR introduces significant architectural changes across multiple system layers with complex validation logic and state management requirements
- Score reflects the substantial complexity of the changes, extensive cross-system dependencies, and potential for edge cases during the legacy-to-new trigger migration
- Pay close attention to the executor changes, collaborative workflow hooks, and trigger constraint validation logic as these contain the most complex state management and validation rules
36 files reviewed, 21 comments
Summary
IN PROGRESS
Type of Change
Testing
IN PROGRESS
Checklist