CacheStore cannot be used on the worker node! queue_get was

Error message

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

What it means

A hard guard panic inside the RocksDB-based CacheStore on a Cube Store worker node: queue_get was called on a store instance where the QueueStore trait methods are deliberately unimplemented, because queue state must live on the router node. The panic indicates an architectural misuse (worker performing a queue read) rather than corrupt data.

Source

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

        _orphaned_timeout: Option<u32>,
        _heartbeat_timeout: Option<u32>,
    ) -> Result<Vec<IdRow<QueueItem>>, CubeError> {
        panic!("CacheStore cannot be used on the worker node! queue_to_cancel was used.")
    }

    async fn queue_list(
        &self,
        _prefix: String,
        _status_filter: Option<QueueItemStatus>,
        _priority_sort: bool,
        _with_payload: bool,
        _caller_process_id: Option<String>,
    ) -> Result<Vec<QueueListItem>, CubeError> {
        panic!("CacheStore cannot be used on the worker node! queue_list was used.")
    }

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

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

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

    async fn queue_retrieve_by_path(
        &self,
        _path: String,
        _allow_concurrency: u32,
        _caller_process_id: Option<String>,
    ) -> Result<QueueRetrieveResponse, CubeError> {
        panic!("CacheStore cannot be used on the worker node! queue_retrieve_by_path was used.")
    }

View on GitHub (pinned to 7d981676b3)

Solutions

Send all queue status polling to the metastore node.
Reconfigure clients so the queue-get address equals the metastore address.
If the client cached endpoints, restart/reconfigure to re-resolve the metastore.
Confirm with logs that the panicking node is indeed a worker.

Example fix

// before: polling worker for build status
status = await workerClient.queueGet(key);
// after
status = await metastoreClient.queueGet(key);

Defensive patterns

Strategy: validation

Validate before calling

if !is_metastore(client.node()) {
    return Err(CubeError::internal("queue_get requires the metastore node"));
}
let resp = client.queueGet(key).await?;

Type guard

fn is_metastore(node: &CubeStoreNode) -> bool {
    matches!(node.role(), NodeRole::Metastore)
}

Prevention

Re-resolve endpoints on reconnect instead of caching worker addresses.
Keep status polling on the same client instance used for enqueue.
Check cubestore routing config when status polls fail.

When it happens

Trigger: Polling a queue item by QueueKey via queue_get against a worker node, e.g. a client checking build progress through the wrong endpoint.

Common situations: Clients storing a worker address after an initial partition upload and later polling queue status on it; misconfigured CUBEJS_DB/cubestore routing options sending status polls to workers.

Related errors

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