risingwavelabs/risingwave · error

since_timestamp should not be specified when no snapshot bac

Error message

since_timestamp should not be specified when no snapshot backfill

What it means

During CREATE MATERIALIZED VIEW handling, the meta node rejects a command that supplies a since_timestamp (snapshot backfill start point) for a job whose type is batch refresh without snapshot backfill semantics. since_timestamp only makes sense when a snapshot backfill upstream exists; otherwise it is meaningless input and the create is rejected via bail!.

Source

Thrown at src/meta/src/stream/stream_manager.rs:671

            upstream_fragment_downstreams,
            init_split_assignment,
            definition: definition.clone(),
            streaming_job: streaming_job.clone(),
            job_type,
            create_type,
            database_resource_group,
            fragment_backfill_ordering,
            cdc_table_snapshot_splits,
            locality_fragment_state_table_mapping,
            is_serverless: is_serverless_backfill,
            streaming_job_model,
            replace_sink,
            refresh_interval_sec,
        };

        let job_type = if let Some(refresh_interval_sec) = refresh_interval_sec {
            if since_timestamp_epoch.is_some() {
                bail!("since_timestamp should not be specified when no snapshot backfill");
            }
            let snapshot_backfill_info = snapshot_backfill_info.ok_or_else(|| {
                anyhow::anyhow!(
                    "batch refresh materialized view must have snapshot backfill upstream"
                )
            })?;
            // Batch refresh jobs must not contain source or source-backfill nodes,
            // because we skip split assignment resolution for them.
            for fragment in info.stream_job_fragments.inner.fragments.values() {
                let mask = fragment.fragment_type_mask;
                if mask.contains(FragmentTypeFlag::Source)
                    || mask.contains(FragmentTypeFlag::SourceScan)
                {
                    bail!(
                        "batch refresh materialized views must not depend on sources directly; \
                         fragment {} has source/source-backfill nodes",
                        fragment.fragment_id
                    );

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Remove the `since`/since_timestamp option from the CREATE statement, or switch to a job type that supports snapshot backfill.
  2. If a point-in-time snapshot is intended, ensure the upstream is a snapshot backfill MV so snapshot_backfill_info is present.
  3. Update client tooling/ORM to not emit since_timestamp for interval-refresh MVs.

Example fix

// before: refresh_interval_sec set AND since_timestamp_epoch set -> error
// after: drop the since option
CREATE MATERIALIZED VIEW mv WITH (refresh = '5 minutes') AS SELECT ...;
-- (no `since` clause unless upstream supports snapshot backfill)
Defensive patterns

Strategy: validation

Validate before calling

-- before running the create, ensure you did not set `since` on a non-snapshot-backfill/refresh MV
-- in app code:
if refresh_interval.is_some() && since_timestamp.is_some() && !snapshot_backfill_supported {
    since_timestamp = None;
}

Try / catch

match meta.create_streaming_job(cmd).await {
    Err(e) if e.to_string().contains("since_timestamp should not be specified") => {
        let mut cmd = cmd; cmd.since_timestamp_epoch = None;
        meta.create_streaming_job(cmd).await
    }
    other => other,
}

Prevention

When it happens

Trigger: Running a create streaming job command where refresh_interval_sec is Some (batch refresh MV) and since_timestamp_epoch is also Some — i.e. the user specified a snapshot cutoff time for a job type that has no snapshot backfill.

Common situations: Users writing `CREATE MATERIALIZED VIEW ... WITH (refresh interval ..., since ...)` on an MV whose upstream is not a snapshot-backfill MV; tooling that always emits since_timestamp; SQL written for a different MV type and reused.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

Related errors


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