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
- Remove the `FOR SYSTEM_TIME AS OF ...` / time travel clause and query the source's current stream instead.
- Use a table (or a source kind that supports time travel) if historical point-in-time reads are required.
- Backfill the needed history into a table, then apply AS OF against that table.
- 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
- Only apply FOR SYSTEM_TIME AS OF to tables, not to sources.
- Check the relation type via catalog/describe before generating as-of queries.
- For historical reads on sources, first backfill into a table.
- Keep generation code that adds time travel opt-in per relation kind.
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
- batch refresh materialized views must not depend on sources
- additional column type {} is not supported for connector {},
- Invalid order key: empty item in `{expr}`
- Invalid order key item `{item}`
- Invalid order key item `{item}` HINT: Supported format is `c
AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11).
Data as JSON: /api/errors/cf3115732dfd7a47.
Report an issue: GitHub.