risingwavelabs/risingwave · error · Error

invalid hummock context {0}

Error message

invalid hummock context {0}

What it means

hummock::Error::InvalidContext indicates that a Hummock operation referenced a context id (HummockContextId — typically a worker/node identifier registered with Hummock) that is unknown or no longer valid. The meta node's Hummock manager keeps a registry of active contexts (compactors, compute nodes); operating on an unregistered or evicted context raises this error.

Source

Thrown at src/meta/src/hummock/error.rs:28

// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

use risingwave_common::catalog::TableId;
use risingwave_hummock_sdk::{HummockContextId, HummockSstableObjectId};
use risingwave_object_store::object::ObjectError;
use risingwave_rpc_client::error::ToTonicStatus;
use sea_orm::DbErr;
use thiserror::Error;

use crate::model::MetadataModelError;

pub type Result<T> = std::result::Result<T, Error>;

#[derive(Error, Debug)]
pub enum Error {
    #[error("invalid hummock context {0}")]
    InvalidContext(HummockContextId),
    #[error("failed to access meta store")]
    MetaStore(
        #[source]
        #[backtrace]
        anyhow::Error,
    ),
    #[error(transparent)]
    ObjectStore(
        #[from]
        #[backtrace]
        ObjectError,
    ),
    #[error("compactor {0} is disconnected")]
    CompactorUnreachable(HummockContextId),
    #[error("compaction group error: {0}")]
    CompactionGroup(String),
    #[error("SST {0} is invalid")]

View on GitHub (pinned to 6469eb736d)

Solutions

1. Identify the stale context id from the error message and check if the node re-registered with a new id
2. Re-register the node/worker with the Hummock meta service and retry with the new context id
3. Clear stale pinning/version state for the old context id
4. Check for race conditions in cluster membership changes (node removal vs in-flight requests)

Example fix

// before
hummock_meta.unpin_snapshot(old_context_id, pinned).await?;
// after
let ctx = hummock_meta.get_context_id(worker_node_id).await
    .expect("worker re-registered");
hummock_meta.unpin_snapshot(ctx, pinned).await?;

// Verify the worker is registered before issuing Hummock ops
let ctx_id = hummock_meta.get_context_id(worker_node_id).await
    .map_err(|_| "worker not registered with hummock")?;

fn is_invalid_context(e: &hummock::Error) -> Option<HummockContextId> {
    match e { hummock::Error::InvalidContext(id) => Some(*id), _ => None }
}

match hummock_result {
    Err(hummock::Error::InvalidContext(ctx)) => {
        // re-resolve context id after re-registration, then retry once
        let new_ctx = hummock_meta.get_context_id(worker_node_id).await?;
        retry_with_context(new_ctx)
    }
    other => other?,
}

When it happens

Trigger: Calling Hummock meta APIs (e.g. unpin, register/scan, commit epoch ops) with a context id of a node that was removed from the cluster, restarted and re-registered under a new id, or never registered.

Common situations: A compute node or compactor was killed and rejoined (its old context id got cleaned up); stale references in compaction tasks after node removal; race between node deregistration and in-flight Hummock requests.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

• table id {} not exist
• Storage error: {0}
• only url starting with 'hummock+' is supported in risectl
• env variable `RW_HUMMOCK_URL` not found. * start the cluste
• only Hummock state store is supported in risectl

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/b038d403cb86979e. Report an issue: GitHub.