fix: Human in the Loop - Canvas labels don't work in Condition/Response blocks

[wingding12]

Summary

Inject block outputs as js variables by their normalized names, allowing users to reference blocks directly without requiring angle bracket syntax in condition expressions.

fixes hitl blocks where canvas labels like humanApproval were not accessible in condition blocks

• skip js reserved words and built-in identifiers
• avoid overwriting existing context variables

Fixes #2962

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

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]

@wingding12 is attempting to deploy a commit to the Sim Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

This PR fixes a critical bug where Human in the Loop blocks couldn't be referenced by their canvas labels in Condition/Response blocks. The fix injects block outputs as JavaScript variables using their normalized names (e.g., humanApproval), allowing direct property access like humanApproval.approved without requiring angle bracket syntax.

Key changes:

• Added RESERVED_IDENTIFIERS set to prevent overwriting JS reserved words and built-in objects
• Created injectBlockVariables() function that maps normalized block names to their outputs in the execution context
• Integrated injection into resolveTagVariables() to make block variables available before tag resolution
• Skips reserved words (console, Math, params, etc.) and existing context variables to avoid collisions

The implementation properly handles edge cases with reserved word filtering and duplicate name checking. This enables the standard workflow pattern of HITL → Condition → downstream blocks that was previously broken.

Confidence Score: 4/5

• This PR is safe to merge with minimal risk - it fixes a critical bug with a targeted change that includes proper safeguards
• The implementation is well-designed with reserved word checking and collision avoidance. However, there's a minor consideration around execution order and one edge case worth noting (normalization collisions), which prevents a perfect score.
• No files require special attention - the single changed file has a focused, well-guarded implementation

Important Files Changed

Filename	Overview
apps/sim/app/api/function/execute/route.ts	Adds injectBlockVariables function to inject block outputs as JS variables by their normalized names, enabling direct reference like humanApproval.approved without angle brackets. Includes reserved word checking and collision avoidance.

Sequence Diagram

sequenceDiagram
    participant User as User Code
    participant RCV as resolveCodeVariables()
    participant RTV as resolveTagVariables()
    participant IBV as injectBlockVariables()
    participant Context as contextVariables
    participant IVM as Isolated VM

    User->>RCV: Execute condition code
    RCV->>RTV: Resolve variables
    RTV->>IBV: Inject block variables
    IBV->>IBV: Check RESERVED_IDENTIFIERS
    IBV->>IBV: Check existing context vars
    IBV->>Context: Add humanApproval = blockData[blockId]
    Context-->>RTV: Variables injected
    RTV->>RTV: Resolve angle bracket tags
    RTV-->>RCV: Code resolved
    RCV->>IVM: Execute with contextVariables
    IVM->>User: humanApproval.approved accessible

Loading

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[AdamRash110]

This is a great approach! The logic in this specific section lookg super clean! I am new to this language. Why was this technique chosen for this project?