cube-js/cube · error

CacheStore cannot be used on the worker node! rocksdb_proper

Error message

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

What it means

Cube Store's worker node uses a stub `CacheStore` implementation in which every `CacheStore` trait method is an unconditional `panic!`. Calling `rocksdb_properties()` (which reads RocksDB statistics like compaction/CF properties) on a worker node — a process that does not own the RocksDB instance — intentionally aborts, because cache operations and metadata inspection are only meaningful on the node hosting the data.

Source

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

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

    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> {

View on GitHub (pinned to 7d981676b3)

Solutions

  1. Route the rocksdb_properties call to the Cube Store node that hosts the data (the master/data node), not a worker.
  2. Check the node's configured role before issuing CacheStore diagnostics; skip or redirect the call on workers.
  3. If clients auto-discover nodes, point them at the correct master address instead of any cluster member.

Example fix

// before: sending cache diagnostics to whichever node the LB picks
store.rocksdb_properties();

// after: only the data node implements the real CacheStore
if !node_config.is_worker {
    store.rocksdb_properties();
} else {
    eprintln!("rocksdb_properties is only available on the data node");
}
Defensive patterns

Strategy: validation

Validate before calling

if let Some(role) = node.role() {
    if role == NodeRole::Worker {
        return Err(anyhow!("rocksdb_properties is only available on the data node; current node is a worker"));
    }
}
node.cache_store().rocksdb_properties()?;

Type guard

fn is_data_node(node: &CubeStoreNode) -> bool {
    !matches!(node.role(), Some(NodeRole::Worker))
}

Try / catch

match std::panic::catch_unwind(AssertUnwindSafe(|| node.cache_store().rocksdb_properties())) {
    Ok(props) => println!("{:?}", props),
    Err(_) => eprintln!("node is a worker; query the data node for RocksDB properties"),
}

Prevention

When it happens

Trigger: Calling the `rocksdb_properties()` method of `CacheStore` on a Cube Store worker node, e.g. an admin/diagnostics request for RocksDB properties routed to a worker instead of the master/data node.

Common situations: Running a Cube Store cluster where the node answering a stats/inspection request is a worker; load balancers or client code pointed at worker ports; tooling that assumes a single-node deployment and calls cache diagnostics without checking the node's role.

Related errors


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