fix(legacy-start): fix legacy start block execution in new executor

[Sg312]

Summary

Fixes legacy start block execution

Type of Change

• Bug fix

Testing

Manual testing

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 3, 2025 6:33pm

[greptile-apps]

Greptile Overview

Greptile Summary

Fixes legacy starter block execution in the new executor by adding explicit handling for the BlockType.STARTER type. After the executor redesign in #1790, the trigger handler wasn't recognizing legacy starter blocks because it only checked for category === 'triggers' or triggerMode === true. This PR adds:

• Early return in canHandle() to recognize BlockType.STARTER blocks
• Early routing in execute() to handle starter blocks via dedicated executeStarterBlock() method
• New executeStarterBlock() method that returns pre-initialized output from block states or falls back to {input: inputs.input || ''}

The fix maintains backward compatibility with legacy workflows using the older starter block type while preserving the new start block behavior introduced in the executor redesign.

Confidence Score: 5/5

• This PR is safe to merge - it's a simple, focused bug fix for legacy block support
• The changes are minimal, well-structured, and follow existing patterns in the codebase. The fix adds explicit handling for a legacy block type that was missed during the executor redesign, using the same approach as the existing handler logic (checking block states first, then falling back). No breaking changes or risky logic modifications.
• No files require special attention

Important Files Changed

File Analysis

Filename	Score	Overview
apps/sim/executor/handlers/trigger/trigger-handler.ts	5/5	Adds explicit handling for legacy starter block type in trigger handler by checking BlockType.STARTER and routing to dedicated executeStarterBlock method

Sequence Diagram

sequenceDiagram
participant Executor
participant TriggerHandler
participant BlockStates
participant StarterBlock
Executor->>TriggerHandler: canHandle(block)
alt block.metadata.id === BlockType.STARTER
TriggerHandler-->>Executor: true
else isTriggerCategory or hasTriggerMode
TriggerHandler-->>Executor: true/false
end
Executor->>TriggerHandler: execute(ctx, block, inputs)
alt block is STARTER type
TriggerHandler->>TriggerHandler: executeStarterBlock()
TriggerHandler->>BlockStates: get(block.id)
alt existingState has output
BlockStates-->>TriggerHandler: existingState.output
TriggerHandler-->>Executor: return existingState.output
else no existing state
TriggerHandler-->>Executor: return {input: inputs.input || ''}
end
else other trigger blocks
TriggerHandler->>BlockStates: get(block.id)
alt existingState exists
BlockStates-->>TriggerHandler: existingState.output
TriggerHandler-->>Executor: return existingState.output
else find starter block
TriggerHandler->>BlockStates: find & get starter block output
alt starter output exists
TriggerHandler->>TriggerHandler: process webhook data
TriggerHandler-->>Executor: return processed output
else use inputs
TriggerHandler-->>Executor: return inputs or {}
end
end
end

Loading

_{1 file reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}