multi_stage leaf measure throws "lacks FROM clause" when sql references raw column

[TheRoot-1]

Describe the bug

When a multi_stage measure's sql references a raw column (no {} measure dependency), and another multi_stage measure references it via {}, the query throws:

Multi stage member 'cube.measure' lacks FROM clause in sub query

To Reproduce

cubes:
  - name: orders
    sql_table: orders

    dimensions:
      - name: id
        sql: id
        type: number
        primary_key: true

      - name: status
        sql: status
        type: string

    measures:
      - name: raw_sum
        sql: amount
        type: sum
        multi_stage: true

      - name: computed
        sql: "{raw_sum}"
        type: number
        multi_stage: true

Query orders.computed with any dimension — the leaf measure raw_sum causes the error.

Root cause

In renderWithQuery (BaseQuery.js), the leaf measure has no children in the member dependency graph, so memberFrom is null. This makes fromMeasures null → fromSubQuery null → fromSql null. The error check at the end of renderWithQuery then throws because subQuery.from is undefined.

Expected behavior

The query should build successfully, falling back to querying the cube's own table when fromSubQuery was never built.

Related

• Unexpected GROUP BY when using multi_stage and referencing dimensions with {} #9241 — different symptom (unexpected GROUP BY) in the same code path (renderWithQuery), but different root cause (non-leaf case with {} references)

[TheRoot-1]

After further investigation, some additional context:

This bug exists in both planners:

• JS planner (BaseQuery.js): throws "Multi stage member '...' lacks FROM clause" — the error that prompted this issue
• Tesseract planner (member_query_planner.rs): silently generates invalid SQL with an empty FROM clause. The leaf is flagged via is_without_member_leaf in plan_for_leaf_cte_query(), but no fallback queries the cube's own table — it produces FromSource::Empty which renders as an empty string

Is this an intended use case?

Probably not. Every multi_stage example in the test suite references another measure via {}. A leaf measure with sql: amount and multi_stage: true (no {} dependency) isn't the intended pattern — the correct approach is a chain where the leaf is a regular measure and multi_stage is on the derived measure that references it.

That said, the current behavior is confusing (JS planner: unhelpful error, Tesseract: silent invalid SQL). A clear validation error at schema compile time — e.g., "multi_stage measures must reference at least one other measure via {}" — would be more helpful than either failure mode.

I have a draft PR that adds a fallback in the JS planner. Happy to adjust the approach if the team prefers a validation error instead.