[Engine] Sub-flow output path is inconsistent (.response. vs .output.)

[ameet]

Component

Flow engine — sub-flow output access

What's wrong?

When flow A calls sub-flow B, the output is sometimes at $.steps.A.response.B.output.X and sometimes at $.steps.A.output.B.output.X. There's no way to know which path at dev time — it only fails at runtime.

Description

We call constants-load from 40+ flows. The output should be at a predictable path, but we've observed both patterns:

// Sometimes works:
$.steps.loadConstants.response.load.output.TEAM

// Sometimes works:
$.steps.loadConstants.output.load.output.TEAM

// Neither is documented as canonical

Scale of impact: We now have a _cfg preamble pattern in 4+ flows that tries BOTH paths:

var _cfg = ((($.steps.loadConstants || {}).output || {}).load || {}).output 
  || (((($.steps.loadConstants || {}).response || {}).load || {}).output) 
  || {};

This is 3 lines of defensive code in every code step that needs config. We've burned multiple debug cycles (2-3 iterations each) on this inconsistency — the structural tests pass because the flow JSON is valid, but runtime returns empty objects.

How we discovered this

• email-process flow: classifyIntent step crashed with "Cannot read properties of undefined (reading 'output')" because it used .response.load.output but the runtime provided .output.load.output
• deal-log flow: resolveOwner step had the same issue
• Both required adding the dual-path _cfg pattern to fix

Suggested fix

1. Document the canonical path — is it .response. or .output.? Pick one.
2. Flatten sub-flow outputs — $.steps.loadConstants.output.TEAM instead of $.steps.loadConstants.output.load.output.TEAM
3. Throw at load time if a step references a path that doesn't exist in the sub-flow's output schema

Source

• Related to [Engine] Sub-flow output double-wrapping forces verbose access paths #66 (sub-flow output double-wrapping)
• Our workaround: _cfg preamble pattern in our flows