cube-js/cube · error

CacheStore cannot be used on the worker node! queue_result_b

Error message

CacheStore cannot be used on the worker node! queue_result_blocking was used.

What it means

CacheStore::queue_result_blocking (blocking wait for a queue result) is another panic! stub on worker nodes in cache_rocksstore.rs. A worker cannot block waiting on queue results since it does not own the queue, so any call panics with this message.

Source

Thrown at rust/cubestore/cubestore/src/cachestore/cache_rocksstore.rs:2068

    async fn queue_ack(&self, _key: QueueKey, _result: Option<String>) -> Result<bool, CubeError> {
        panic!("CacheStore cannot be used on the worker node! queue_ack was used.")
    }

    async fn queue_result(
        &self,
        _key: QueueKey,
        _external_id: Option<String>,
    ) -> Result<Option<QueueResultResponse>, CubeError> {
        panic!("CacheStore cannot be used on the worker node! queue_result was used.")
    }

    async fn queue_result_blocking(
        &self,
        _key: QueueKey,
        _timeout: u64,
    ) -> Result<Option<QueueResultResponse>, CubeError> {
        panic!("CacheStore cannot be used on the worker node! queue_result_blocking was used.")
    }

    async fn queue_merge_extra(&self, _key: QueueKey, _payload: String) -> Result<(), CubeError> {
        panic!("CacheStore cannot be used on the worker node! queue_merge_extra was used.")
    }

    async fn compaction(&self) -> Result<(), CubeError> {
        panic!("CacheStore cannot be used on the worker node! compaction was used.")
    }

    async fn info(&self) -> Result<CachestoreInfo, CubeError> {
        panic!("CacheStore cannot be used on the worker node! info was used.")
    }

    async fn eviction(&self) -> Result<EvictionResult, CubeError> {
        panic!("CacheStore cannot be used on the worker node! eviction was used.")
    }

View on GitHub (pinned to 7d981676b3)

Solutions

  1. Run the blocking result wait against the master node's store or a remote client to it
  2. Fix node role assignment so queue-consuming/blocking code only runs on the master
  3. If intentionally testing, instantiate the non-worker CacheStore variant

Example fix

// before
let r = worker_store.queue_result_blocking(key, timeout).await?;
// after
let r = master_client.queue_result_blocking(key, timeout).await?;
Defensive patterns

Strategy: validation

Validate before calling

if !is_master { return Err(CubeError::internal("blocking queue_result requires master node")); }
let r = master_client.queue_result_blocking(key, timeout).await?;

Type guard

fn is_queue_capable(store: &dyn CacheStore) -> bool { node_role == NodeRole::Master }

Try / catch

let r = std::panic::catch_unwind(AssertUnwindSafe(|| master_client.queue_result_blocking(key, timeout))).map_err(|_| CubeError::internal("queue_result_blocking called on worker node"))?;

Prevention

When it happens

Trigger: Calling CacheStore::queue_result_blocking(key, timeout) on a worker-node store instance (cache_rocksstore.rs:2068).

Common situations: Blocking result wait executed inside a worker-mode CubeStore process; a deployment where the query-orchestration loop runs on workers instead of the master.

Related errors


AI-assisted analysis of cube-js/cube@7d981676b3 (2026-09-02). Data as JSON: /api/errors/df68d7ce39fc0aeb. Report an issue: GitHub.