risingwavelabs/risingwave · error

Time travel is not supported for the source

Error message

Time travel is not supported for the source

What it means

Creating a `LogicalSource` fails with `bail!` when the source is created with an `AS OF` (time travel) clause but the source kind does not support time travel (its `support_time_travel()` returns false). This is a user-facing validation error raised at plan construction, e.g. for sources (like certain CDC or shared sources) whose snapshot/history cannot be queried at a past timestamp.

Source

Thrown at src/frontend/src/optimizer/plan_node/logical_source.rs:92

        as_of: Option<AsOf>,
    ) -> Result<Self> {
        // XXX: should we reorder the columns?
        // The order may be strange if the schema is changed, e.g., [foo:Varchar, _rw_kafka_timestamp:Timestamptz, _row_id:Serial, bar:Int32]
        // related: https://github.com/risingwavelabs/risingwave/issues/16486
        // The order does not matter much. The columns field is essentially a map indexed by the column id.
        // It will affect what users will see in `SELECT *`.
        // But not sure if we rely on the position of hidden column like `_row_id` somewhere. For `projected_row_id` we do so...
        let core = generic::Source {
            catalog: source_catalog,
            column_catalog,
            row_id_index,
            kind,
            ctx,
            as_of,
        };

        if core.as_of.is_some() && !core.support_time_travel() {
            bail!("Time travel is not supported for the source")
        }

        let base = PlanBase::new_logical_with_core(&core);

        let output_exprs = Self::derive_output_exprs_from_generated_columns(&core.column_catalog)?;
        let (core, output_row_id_index) = core.exclude_generated_columns();

        Ok(LogicalSource {
            base,
            core,
            output_exprs,
            output_row_id_index,
        })
    }

    pub fn with_catalog(
        source_catalog: Rc<SourceCatalog>,
        kind: SourceNodeKind,

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Remove the `FOR SYSTEM_TIME AS OF ...` / time travel clause and query the source's current stream instead.
  2. Use a table (or a source kind that supports time travel) if historical point-in-time reads are required.
  3. Backfill the needed history into a table, then apply AS OF against that table.
  4. Check RisingWave docs/version for which source kinds support time travel and upgrade if support was added later.

Example fix

// before
SELECT * FROM my_source FOR SYSTEM_TIME AS OF '2026-01-01 00:00:00';
// after
SELECT * FROM my_source; -- time travel unsupported for sources
Defensive patterns

Strategy: validation

Validate before calling

// Check relation kind before issuing a time-travel query.
let kind = rw.describe("my_source")?.kind;
if kind != RelationKind::Table {
    return Err("time travel requires a table, not a source");
}
// then it is safe to add: FOR SYSTEM_TIME AS OF <ts>

Type guard

fn supports_time_travel(kind: RelationKind) -> bool {
    matches!(kind, RelationKind::Table | RelationKind::DmlTailSupportedTable)
}

Try / catch

match err.message.contains("Time travel is not supported") {
    true => fallback_to_current_scan(sql_without_as_of),
    false => return Err(err),
}

Prevention

When it happens

Trigger: Executing `SELECT ... FROM <source> FOR SYSTEM_TIME AS OF <timestamp>` (or creating a materialized view with such time travel) where `<source>` is a source whose `support_time_travel()` is false (e.g. a shared source / non-table source without time-travel support).

Common situations: Users try flashback/as-of queries against a source (not a table/DML-tail-supported relation), or after a version change enabled time travel only for some source kinds; also occurs when scripting generic time-travel queries across all relations.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


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