fix(resolver): add both new and old workflow blocks for backwards compatibility

[waleedlatif1]

Summary

• add both new and old workflow blocks for backwards compatibility for response block

Type of Change

• Bug fix

Testing

Tested manually

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	Review	Updated (UTC)
docs	Skipped		Jan 7, 2026 3:53pm

[greptile-apps]

Greptile Summary

This PR fixes a backwards compatibility gap in the block resolver by extending support for the workflow_input block type to use the same reference path fallback logic as workflow blocks. When child workflows with Response blocks now return data in the new format ({data, status, headers} instead of {response: {data, status, headers}}), the resolver can now correctly handle old reference patterns like <workflow1.result.response.data> for both block types.

Key Changes:

• Extended backwards compatibility fallback to support both workflow and workflow_input block types
• Introduced isWorkflowBlock variable to avoid code duplication and improve readability
• Added comprehensive test coverage with two real-world scenarios demonstrating correct behavior for workflow_input type
• Tests verify both new format references (<workflow1.result.data>) and old format with fallback (<workflow1.result.response.data>) work correctly

Confidence Score: 5/5

• This PR is safe to merge with minimal risk. The changes are targeted, well-tested, and fix a legitimate backwards compatibility issue.
• Score reflects: (1) minimal, focused code changes affecting only the backwards compatibility fallback logic, (2) the fix correctly mirrors existing workflow block handling for workflow_input, (3) comprehensive test coverage including real-world scenarios, (4) the logic is sound - only activates when output.result.response is undefined, preventing false positives, (5) no changes to public APIs or existing behavior for other block types.
• No files require special attention. The PR is well-implemented.

Important Files Changed

Filename	Overview
apps/sim/executor/variables/resolvers/block.ts	Extends backwards compatibility fallback for workflow block resolution to support both workflow and workflow_input block types. The change is minimal, precise, and correctly introduces a helper variable to avoid code duplication. The logic properly checks that output.result.response is undefined before applying the fallback, ensuring it only activates for new format outputs.
apps/sim/executor/variables/resolvers/block.test.ts	Adds comprehensive test coverage for the workflow_input block type backwards compatibility. Includes two critical real-world test scenarios covering accessing entire response objects and drilling into nested fields. Tests properly validate both new and old reference patterns work correctly, with clear comments explaining the test purpose.

Sequence Diagram

sequenceDiagram
    participant User as User Code
    participant Resolver as BlockResolver
    participant Cache as Block Cache
    participant Fallback as Backwards Compat

    User->>Resolver: "resolve with old path"
    Resolver->>Cache: "getBlockOutput(blockId)"
    Cache-->>Resolver: "{result: {data, status, headers}}"
    
    Note over Resolver: Try original path
    Resolver->>Fallback: "navigatePath() original"
    Fallback-->>Resolver: "undefined"
    
    Note over Resolver: Check block type
    Resolver->>Resolver: "isWorkflowBlock?"
    
    Note over Resolver: Check new format
    Resolver->>Resolver: "output.result.response undefined?"
    
    Note over Resolver: Apply fallback
    Resolver->>Fallback: "navigatePath() adjusted path"
    Fallback-->>Resolver: "value found"
    
    Resolver-->>User: "resolved value"

Loading