CacheStore cannot be used on the worker node! cache_delete w

Error message

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

What it means

ClusterCacheStoreClient (worker-node CacheStore) panics on cache_delete; workers do not perform individual cache-key deletions locally. Deletes must go through the master/cluster cache path to keep eviction consistent across the cluster.

Source

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

    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.")
    }

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

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

    async fn cache_keys(&self, _prefix: String) -> Result<Vec<IdRow<CacheItem>>, CubeError> {
        panic!("CacheStore cannot be used on the worker node! cache_keys was used.")
    }

    async fn cache_incr(&self, _: String) -> Result<IdRow<CacheItem>, CubeError> {
        panic!("CacheStore cannot be used on the worker node! cache_incr was used.")
    }

    async fn queue_all(&self, _limit: Option<usize>) -> Result<Vec<QueueAllItem>, CubeError> {
        panic!("CacheStore cannot be used on the worker node! queue_all was used.")
    }

View on GitHub (pinned to 7d981676b3)

Solutions

Direct cache_delete calls to the master node or the cluster cache client.
Use the cluster-aware invalidation API so the delete is applied where the cache lives.
Check role configuration and request routing for the invalidating component.

Example fix

// before
worker_cache_store.cache_delete(key).await?; // panics on worker
// after
cluster_cache_client.cache_delete(key).await?; // invalidated via master

Defensive patterns

Strategy: validation

Validate before calling

if node_role() == Role::Worker {
    return Err(CubeError::internal("cache_delete is master-only"));
}
cache_store.cache_delete(key).await?;

Type guard

fn is_master_cache(store: &dyn CacheStore) -> bool {
    std::any::Any::type_id(store) != std::any::TypeId::of::<ClusterCacheStoreClient>()
}

Try / catch

if is_worker_cache_stub(cache_store) {
    return Err(CubeError::internal("cache_delete must be delegated to the master"));
}
cache_store.cache_delete(key).await?;

Prevention

Route invalidation requests to the master node
Use the cluster invalidation API rather than per-node deletes
Check request routing for cache invalidation endpoints
Inject the role-appropriate CacheStore at construction time

When it happens

Trigger: Calling cache_delete(key) on a worker node's ClusterCacheStoreClient — e.g. invalidating a specific query cache entry on the wrong node.

Common situations: Cache-invalidation hooks executing on workers; API routing sending invalidation requests to worker instances.

Related errors

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