risingwavelabs/risingwave · error · BatchError

Failed to execute time travel query

Error message

Failed to execute time travel query

What it means

BatchError::TimeTravel wraps an anyhow::Error raised when executing a time travel query — a query against a historical snapshot of a table (time travel / historical version reads). The batch frontend/engine failed while resolving or reading the historical version, and the underlying root cause is preserved in the source.

Source

Thrown at src/batch/src/error.rs:153

    ServingVnodeMappingNotFound(FragmentId),

    #[error("Streaming vnode mapping has not been initialized")]
    StreamingVnodeMappingNotInitialized,

    #[error("Streaming vnode mapping not found for fragment {0}")]
    StreamingVnodeMappingNotFound(FragmentId),

    #[error("Not enough memory to run this query, batch memory limit is {0} bytes")]
    OutOfMemory(u64),

    #[error("Failed to spill out to disk")]
    Spill(
        #[from]
        #[backtrace]
        opendal::Error,
    ),

    #[error("Failed to execute time travel query")]
    TimeTravel(
        #[source]
        #[backtrace]
        anyhow::Error,
    ),
}

// Serialize/deserialize error.
impl From<memcomparable::Error> for BatchError {
    fn from(m: memcomparable::Error) -> Self {
        Self::Serde(m.into())
    }
}
impl From<ValueEncodingError> for BatchError {
    fn from(e: ValueEncodingError) -> Self {
        Self::Serde(e.into())
    }
}

View on GitHub (pinned to 6469eb736d)

Solutions

1. Query a more recent timestamp within the retention window.
2. Increase the retention/history configuration so older snapshots are kept.
3. Verify the target table supports time travel and the timestamp format/semantics used.
4. Inspect the wrapped anyhow source (chain) for the underlying Hummock/storage error and fix that cause.

Example fix

-- before
SELECT * FROM t FOR SYSTEM_TIME AS OF '2020-01-01 00:00:00';  -- snapshot already GC'd

-- after
SELECT * FROM t FOR SYSTEM_TIME AS OF now() - INTERVAL '10 minutes';  -- within retention

// Before running, check the AS OF timestamp is within retention:
// if ts < now - retention_window { use a newer ts or raise retention config }

match result {
    Err(BatchError::TimeTravel(src)) => {
        // inspect src (anyhow chain) for retention/GC errors and pick a newer snapshot
    }
    other => other?,
}

When it happens

Trigger: Running `SELECT ... FROM table FOR SYSTEM_TIME AS OF <timestamp/version>` where the requested snapshot is outside the retention window, the underlying Hummock version/SST no longer exists, or the internal time-travel read fails.

Common situations: Querying a timestamp older than the configured retention period, time travel queried against a table without historical data support, cluster upgraded/collections GC'd so old snapshots are gone.

Understand the failure class

Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.

Related errors

• Storage error: {0}
• Cannot find the snapshot id in the iceberg table.
• Time-travel version expired: table {table_id}, epoch {epoch}
• query_epoch not set in distributed lookup join
• Array error: {0}

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