Dev mode: `/cubejs-api/v1/meta` hangs indefinitely on any data model edit made after a query has run (regression in 1.7, works in 1.6)

[shivamsaryar]

Summary

In development mode, editing a data model file causes /cubejs-api/v1/meta to block forever — but only if a query has been executed since startup. The Playground sits on "Loading meta information..." permanently. Only a restart clears it.

Both conditions are required, which makes it look intermittent.

Reproduction

1. Start Cube in dev mode with a single cube (sql_table, a few dimensions, a count measure).
2. Wait for /cubejs-api/v1/meta to return 200.
3. Run any query via /cubejs-api/v1/load.
4. Make any content change to the model file — appending a comment line is enough.
5. Request /cubejs-api/v1/meta.

Expected: meta returns the recompiled model.
Actual: the request never returns.

Isolation

sequence	/v1/meta result
edit model, no query run since startup	200 in 0.8s
query only, no edit	200 in 0.009s
query, then edit model	hangs indefinitely

Additional observations during the hang:

• Container CPU ~1%, so it is not a spin loop.
• /playground/files and /playground/context still respond in ~15ms, so the event loop is not blocked.
• No SQL is issued for the pending refresh cycle; logs show Previous interval #N was not finished with 30000 interval repeating.
• It never recovers. Observed still hanging after several minutes.
• touch on the model file (mtime only, no content change) does not trigger it.

Versions

image	result
cubejs/cube:v1.6.72-jdk	works — repeated query→edit cycles reload in ~0.7s
cubejs/cube:v1.7.0-jdk	hangs
cubejs/cube:v1.7.19-jdk	hangs
cubejs/cube:v1.7.25-jdk	hangs

v1.7.0 is already affected, so this appears to span the entire 1.7 line rather than being a late regression.

Ruled out

None of these changed the behaviour:

• Moving Cube Store's data off the Docker bind mount (mounting only model/ rather than the project root)
• CUBEJS_TRANSPILATION_WORKER_THREADS=false
• CUBEJS_SCHEDULED_REFRESH_TIMER=false together with CUBEJS_REFRESH_WORKER=false
• An explicit cube-level refresh_key with a long every
• CUBEJS_CACHE_AND_QUEUE_DRIVER=memory
• CUBEJS_DB_MAX_POOL=20 with CUBEJS_CONCURRENCY=4
• sql: instead of sql_table:

Environment

• Docker image cubejs/cube:<version>-jdk, platform: linux/amd64 on Apple Silicon (Docker Desktop, macOS)
• CUBEJS_DEV_MODE=true
• Driver: databricks-jdbc

Caveat

Reproduced only against databricks-jdbc, where each query takes ~5–9s. I have not verified whether a fast-responding driver also reproduces it, so query duration may be a factor.