Skip to content

Conversation

@icecrasher321
Copy link
Collaborator

Summary

IN PROGRESS

Type of Change

  • New feature

Testing

IN PROGRESS

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
Copy link

vercel bot commented Sep 13, 2025

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

Project Deployment Preview Comments Updated (UTC)
sim Ready Ready Preview Comment Sep 17, 2025 6:05pm
1 Skipped Deployment
Project Deployment Preview Comments Updated (UTC)
docs Skipped Skipped Sep 17, 2025 6:05pm

@vercel vercel bot temporarily deployed to Preview – docs September 13, 2025 19:45 Inactive
@icecrasher321 icecrasher321 changed the title improvement(start-block): move away to split triggers improvement(start-block): move away from unified start block to split triggers Sep 13, 2025
@vercel vercel bot temporarily deployed to Preview – docs September 17, 2025 01:42 Inactive
@icecrasher321 icecrasher321 marked this pull request as ready for review September 17, 2025 01:42
Copy link
Contributor

@greptile-apps greptile-apps bot left a 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

Edit Code Review Bot Settings | Greptile

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants