MEASURE(AGG(...)) causes 30-60s CPU spin before failing with 'Physical plan does not support logical expression'

[hank-sq]

Describe the bug

When a CubeSQL query contains a nested aggregate function inside MEASURE() — e.g., MEASURE(SUM(column)) — the query planner spins the CPU for 30-60 seconds before eventually returning an error. During this time, the single-threaded Cube process is completely blocked and cannot serve any other requests.

The correct syntax is either MEASURE(column) or SUM(column) — these are alternatives, not composable. However, instead of immediately rejecting the invalid nesting with a parse/validation error, Cube attempts to build a physical plan and gets stuck in an expensive planning loop.

Expected behavior

MEASURE(SUM(...)) (and similar nesting like MEASURE(COUNT(...)), MEASURE(AVG(...)), etc.) should be rejected immediately during SQL parsing or logical plan validation — ideally in under 100ms — with a clear error message like:

"Nested aggregate functions inside MEASURE() are not supported. Use MEASURE(column) or SUM(column), not MEASURE(SUM(column))."

Actual behavior

Cube spins the CPU for 30-60 seconds, blocking all concurrent requests, then returns:

This feature is not implemented: Physical plan does not support logical expression SUM(#ItemSales.sales_quantity)

The duration field in the error log confirms the excessive time (e.g., "duration": 64902 — nearly 65 seconds for a query that never reaches the database).

To Reproduce

Data model (YAML)

cubes:
  - name: ItemSales
    sql: "SELECT * FROM some_table"
    dimensions:
      - name: item_name
        sql: "{CUBE}.item_name"
        type: string
      - name: local_date
        sql: "{CUBE}.local_date"
        type: time
      - name: check_state
        sql: "{CUBE}.check_state"
        type: string
    measures:
      - name: sales_quantity
        sql: "CASE WHEN {CUBE}.transaction_type = 'SALE' THEN {CUBE}.quantity ELSE 0 END"
        type: sum

Query (via SQL API — REST or Postgres wire protocol)

SELECT
  ItemSales.item_name,
  MEASURE(SUM(ItemSales.sales_quantity)) AS total_quantity
FROM ItemSales
WHERE ItemSales.local_date >= '2026-01-11'
  AND ItemSales.local_date <= '2026-04-10'
  AND ItemSales.check_state = 'CLOSED_CHECK'
GROUP BY
  ItemSales.item_name
HAVING MEASURE(SUM(ItemSales.sales_quantity)) > 0
ORDER BY total_quantity DESC
LIMIT 20

Expected result

Immediate error (< 1 second) rejecting the query.

Actual result

~30-65 second hang, then:

{
  "error": "This feature is not implemented: Physical plan does not support logical expression SUM(#ItemSales.sales_quantity)"
}

Impact

This is an availability/DoS concern. Because Cube's query planner is single-threaded, a single MEASURE(SUM(...)) query blocks all other traffic for 30-60 seconds. In our production environment, a client submitted ~34 such queries in rapid succession, causing a sustained outage where no other requests could be served.

We've added a workaround on our API gateway layer to reject these patterns with a 400 before they reach Cube, but this should ideally be handled in Cube itself — both the immediate rejection and preventing the CPU spin.

Additional context

The table of valid aggregate functions from the Cube SQL API docs confirms that MEASURE(column) and SUM(column) are alternatives for sum-type measures. The docs do not document MEASURE(SUM(...)) as valid syntax, and the error confirms it isn't — the issue is purely that the rejection path is catastrophically slow.

Measure type	Valid aggregate functions
sum	MEASURE or SUM
count	MEASURE or COUNT
avg	MEASURE or AVG
min	MEASURE or MIN
max	MEASURE or MAX

None of these support nesting (e.g., MEASURE(SUM(...)), MEASURE(COUNT(...))).

[hank-sq]

Another invalid SQL API shape seems to fit the same broader pattern as this issue: MEASURE(view_dimension).

Example:

SELECT
  MEASURE(ItemSales.category_name) AS category,
  MEASURE(ItemSales.sales_gross_amount) AS gross_sales,
  MEASURE(ItemSales.items_sold_count) AS quantity_sold
FROM ItemSales
WHERE ItemSales.local_date = '2026-04-15'
  AND ItemSales.transaction_type = 'SALE'
GROUP BY ItemSales.category_name
ORDER BY gross_sales DESC
LIMIT 10

This is invalid because ItemSales.category_name is a dimension, not a measure, so ideally it should be rejected immediately instead of entering an expensive rewrite / planning path.

What we saw on Cube v1.6.29:

• The control query with plain ItemSales.category_name AS category stayed narrow (2 measures + 1 dimension) and completed normally.
• The malformed MEASURE(ItemSales.category_name) version widened dramatically and eventually timed out.
• In staging, initial SQL API planning was still fast (~22ms), but the normalized query expanded to 44 measures + 49 dimensions before timing out after ~110s.
• In production, the same malformed query family sometimes also paid an extra ~45-90s in planning / SQL generation before timing out.

So the shared pattern with MEASURE(AGG(...)) here seems to be:

1. an invalid SQL API shape is accepted instead of being rejected early,
2. Cube widens / expensively processes it internally,
3. the request burns a lot of time / CPU before eventually failing.

I still think TRIM(view_dimension) in #10712 is a separate issue because that query shape is valid SQL and should work. But MEASURE(view_dimension) looks like another case that belongs in this bucket of invalid SQL not being rejected early enough.