cube-js/cube · error

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

Error message

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

What it means

This is the worker-node stub for `CacheStore::wipe()`, which deletes the local cache. Workers do not own a RocksDB cache instance, so calling `wipe()` there cannot do anything meaningful and panics by design. Wiping the cache is an operation reserved for the node that actually stores the data.

Source

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

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

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

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

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

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

crate::di_service!(ClusterCacheStoreClient, [CacheStore]);

#[cfg(test)]
mod tests {
    use super::*;
    use crate::cachestore::{CacheEvictionPolicy, EvictionFinishedResult};
    use crate::config::{init_test_logger, ConfigObjImpl, CubeServices};
    use crate::CubeError;

    #[tokio::test]
    async fn test_cachestore_migration() -> Result<(), CubeError> {
        init_test_logger().await;

        let (_, cachestore) = RocksCacheStore::prepare_test_cachestore_from_fixtures(
            "cachestore-migration",

View on GitHub (pinned to 7d981676b3)

Solutions

  1. Execute the cache wipe only on the data/master node that owns the RocksDB store.
  2. Filter worker nodes out of any script or job that performs CacheStore maintenance.
  3. Use the cluster's admin/control-plane API (which routes to the correct node) instead of calling the store directly.

Example fix

// before: wiping cache on all nodes
for node in cluster.nodes {
    node.cache_store().wipe();
}

// after: wipe only where the cache lives
for node in cluster.nodes.iter().filter(|n| !n.is_worker) {
    node.cache_store().wipe();
}
Defensive patterns

Strategy: validation

Validate before calling

if node.is_worker() {
    eprintln!("skipping cache wipe: workers hold no local cache");
    return Ok(());
}
node.cache_store().wipe()?;

Type guard

fn can_wipe_cache(node: &CubeStoreNode) -> bool {
    !node.is_worker()
}

Try / catch

let result = std::panic::catch_unwind(AssertUnwindSafe(|| node.cache_store().wipe()));
if result.is_err() {
    eprintln!("wipe is unsupported on worker nodes; run it on the data node");
}

Prevention

When it happens

Trigger: Invoking `wipe()` on `CacheStore` in a Cube Store worker process, e.g. a cache-invalidation or maintenance command executed against a worker instead of the data node.

Common situations: Ops automation (cron jobs, kubectl exec into the wrong pod) issuing cache wipes to every cluster member; clients broadcasting admin commands cluster-wide; single-node scripts reused unchanged in a multi-node deployment.

Related errors


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