cube-js/cube · error

CacheStore cannot be used on the worker node! cache_all was

Error message

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

What it means

ClusterCacheStoreClient is the CacheStore implementation used on Cube Store worker nodes in a cluster. Workers do not own the local rocksdb cache — all cache mutations are supposed to go through the cluster/metastore path — so every CacheStore trait method panics with a message naming the method that was used. Seeing this means code invoked a local-cache operation directly on a worker node.

Source

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

    async fn wipe(&self) -> Result<(), CubeError> {
        // Wiping requires dropping and reopening the RocksDB from scratch, which a bare inner
        // store cannot do to itself (it cannot rebuild its own Arc / swap the state). The
        // registered production impl is always LazyRocksCacheStore, which owns the teardown.
        Err(CubeError::internal(
            "cachestore wipe is only supported through LazyRocksCacheStore".to_string(),
        ))
    }
}

crate::di_service!(RocksCacheStore, [CacheStore]);
crate::di_service!(CacheStoreRpcClient, [CacheStore]);

pub struct ClusterCacheStoreClient {}

#[async_trait]
impl CacheStore for ClusterCacheStoreClient {
    async fn cache_all(&self, _limit: Option<usize>) -> Result<Vec<IdRow<CacheItem>>, CubeError> {
        panic!("CacheStore cannot be used on the worker node! cache_all was used.")
    }

    async fn cache_set(
        &self,
        _item: CacheItem,
        _update_if_not_exists: bool,
    ) -> Result<bool, CubeError> {
        panic!("CacheStore cannot be used on the worker node! cache_set was used.")
    }

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

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

View on GitHub (pinned to 7d981676b3)

Solutions

  1. Ensure the operation runs on the master/head node, not a worker — route cache management calls to the master.
  2. Check node configuration (cluster role flags) so cache-owning roles are assigned to the node performing cache operations.
  3. If writing Cube Store code, obtain the shared/cluster cache client (e.g. from the metastore) instead of the worker-local ClusterCacheStoreClient.

Example fix

// before
let items = worker_cache_store.cache_all(limit).await?; // panics on worker
// after
let items = cluster.master_cache_store().cache_all(limit).await?; // route via master
Defensive patterns

Strategy: validation

Validate before calling

// before calling cache_all, confirm the store is not the worker stub
if store_is_worker_client(cache_store) {
    return Err("cache_all must run on the master node".into());
}
let items = cache_store.cache_all(limit).await?;

Type guard

fn is_cluster_worker_client(store: &dyn CacheStore) -> bool {
    // ClusterCacheStoreClient is the worker stub; detect via downcast or role flag
    std::any::Any::type_id(store) == std::any::TypeId::of::<ClusterCacheStoreClient>() || node_role() == Role::Worker
}

Try / catch

// panics are not catchable in Rust; guard before calling
if node_role() == Role::Worker {
    return Err(CubeError::internal("cache_all is master-only"));
}
let items = cache_store.cache_all(limit).await?;

Prevention

When it happens

Trigger: Calling cache_all() on a ClusterCacheStoreClient (worker-node cache store), e.g. via cache-management/eviction logic that assumes it is running on a master node.

Common situations: Misconfigured cluster where a node started as worker receives master-only cache requests; application or admin tooling hitting the wrong node's endpoint; a bug routing cache operations through the wrong CacheStore instance.

Related errors


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