/v1/cubesql endpoint doesn't return 'Continue wait' for long-running queries

[hank-sq]

Description

The REST API documentation states that both /v1/load and /v1/cubesql endpoints support cache control and the Continue wait mechanism:

/v1/load and /v1/cubesql endpoints of the REST API allow to control the in-memory cache behavior.

And in the Continue wait section:

If the request takes too long to be processed, the REST API responds with { "error": "Continue wait" } and the status code 200.

However, when making a request to /v1/cubesql with a long-running query, the request hangs indefinitely instead of returning {"error": "Continue wait"} after continueWaitTimeout.

Expected behavior

After continueWaitTimeout (e.g., 20 seconds), the /v1/cubesql endpoint should return {"error": "Continue wait"} with status 200, allowing clients to poll—the same behavior as /v1/load.

Actual behavior

The request hangs indefinitely, never returning a Continue wait response.

Configuration

• continueWaitTimeout: 20 seconds (configured via orchestratorOptions.continueWaitTimeout in cube.js)
• Cube.js version: 1.6.8

Steps to reproduce

1. Configure continueWaitTimeout to a short value (e.g., 20 seconds)
2. Send a POST request to /v1/cubesql with a query that takes longer than the timeout
3. Observe that the request hangs instead of returning {"error": "Continue wait"}

Question

Is Continue wait intentionally not supported for /v1/cubesql, or is this a bug? If intentional, the documentation should be updated to clarify this difference from /v1/load.

[draymondxie]

Met that issue too, appreciate the follow-up fixing.