fix: resolve CODE step result variables in workflow templates

[jnMetaCode]

Summary

• Fixes workflow template variable substitution for CODE step outputs referenced via {{step.result.field}} path
• The getWorkflowRunContext function now exposes step results both at the top level ({{step.field}}) and under a result key ({{step.result.field}}), so both access patterns resolve correctly
• Adds tests for the new behavior in both getWorkflowRunContext and variable-resolver

Problem

When a CODE step in a workflow produces output (e.g., { memberName: "Mike Chen", eventName: "Microsoft Gala" }), subsequent steps like SEND_EMAIL that reference these values using {{transform-step-001.result.memberName}} get undefined instead of the actual value. This is because getWorkflowRunContext strips the result wrapper from step outputs, so only {{step.field}} works but {{step.result.field}} does not.

Fix

Modified getWorkflowRunContext in packages/twenty-shared/src/workflow/utils/getWorkflowRunContext.ts to spread the result object at the top level AND include it under a result key. This preserves backward compatibility with existing UI-generated variables ({{step.field}}) while also supporting the {{step.result.field}} path that users naturally write based on the workflow run state structure.

Test plan

• Verify {{step.field}} still resolves correctly (backward compatibility)
• Verify {{step.result.field}} now resolves correctly
• Verify multi-variable strings like {{step.result.a}} and {{step.result.b}} work
• Run existing unit tests for getWorkflowRunContext and variable-resolver

Fixes #17109

🤖 Generated with Claude Code

[greptile-apps]

Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.

[charlesBochet]

@jnMetaCode Please stop opening AI generated PR on this repository. You are not helping us and harming the community. This will be the only warning before ban: one more and that's it

[github-actions]

Welcome!

Hello there, congrats on your first PR! We're excited to have you contributing to this project.
By submitting your Pull Request, you acknowledge that you agree with the terms of our Contributor License Agreement.

Generated by 🚫 dangerJS against 4675b78

[cubic-dev-ai]

No issues found across 3 files

[sentry]

Bug: The spread syntax { ...result, result } in getWorkflowRunContext overwrites the result property of a step's output object, causing data loss if that key already exists.
_{Severity: HIGH}

Suggested Fix

To preserve the original result property if it exists, reverse the order of the properties in the object literal to { result, ...result }. This ensures that the spread properties from the result object will overwrite the initial result key, effectively preserving the original key-value pair from the step's output.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: packages/twenty-shared/src/workflow/utils/getWorkflowRunContext.ts#L13-L15

Potential issue: In the `getWorkflowRunContext` function, when a step's output
(`result`) is an object, the code uses `{ ...result, result }` to construct the new
context. If the original `result` object already contains a property named `result`,
this syntax overwrites that property's value with the entire `result` object itself. For
example, an output of `{ "result": "success", "userId": 123 }` is incorrectly
transformed into `{ "userId": 123, "result": { "result": "success", "userId": 123 } }`.
This leads to silent data corruption, as the original value of the `result` property is
lost, which can break subsequent workflow steps that depend on it.

_{Did we get this right? 👍 / 👎 to inform future reviews.}