Skip to content

Conversation

@Sg312
Copy link
Contributor

@Sg312 Sg312 commented Nov 3, 2025

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

vercel bot commented Nov 3, 2025

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

1 Skipped Deployment
Project Deployment Preview Comments Updated (UTC)
docs Skipped Skipped Nov 3, 2025 6:33pm

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

@Sg312 Sg312 merged commit fb445b1 into staging Nov 3, 2025
9 checks passed
@waleedlatif1 waleedlatif1 deleted the fix/legacy-start branch November 6, 2025 01:25
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.

2 participants