risingwavelabs/risingwave · error · anyhow::Error

missing lagging barriers for direct log-store start from sna

Error message

missing lagging barriers for direct log-store start from snapshot epoch {}

What it means

For a creating job that reads directly from the log store starting at a snapshot epoch, the code must find the lagging barriers covering the gap from the snapshot epoch; if the search loop ends without collecting any initial barrier, it errors, since it cannot establish the correct starting log epochs.

Source

Thrown at src/meta/src/barrier/checkpoint/independent_job/creating_job/mod.rs:558

                    BarrierInfo {
                        prev_epoch: TracedEpoch::new(Epoch(prev_epoch)),
                        curr_epoch: TracedEpoch::new(Epoch(pending_barrier.curr_epoch())),
                        kind: if pending_barrier.kind.is_checkpoint() {
                            BarrierKind::Checkpoint(take(&mut pending_non_checkpoint_barriers))
                        } else {
                            BarrierKind::Barrier
                        },
                    },
                );
                prev_epoch = pending_barrier.curr_epoch();
            }
            assert_eq!(
                new_upstream_barrier_prev_epoch, prev_epoch,
                "new upstream barrier prev epoch should match the latest pending log-store epoch"
            );
        }
        let Some(initial_barrier) = initial_barrier else {
            return Err(anyhow::anyhow!(
                "missing lagging barriers for direct log-store start from snapshot epoch {}",
                snapshot_epoch
            )
            .into());
        };
        assert!(initial_barrier.kind.is_checkpoint());
        Ok((initial_barrier, barriers))
    }

    fn recover_consuming_snapshot(
        job_id: JobId,
        upstream_table_log_epochs: &UpstreamTableLogEpochs,
        snapshot_epoch: u64,
        committed_epoch: u64,
        upstream_barrier_info: &BarrierInfo,
        info: CreatingJobInfo,
        backfill_order_state: BackfillOrderState,
        version_stat: &HummockVersionStats,

View on GitHub (pinned to 6469eb736d)

Solutions

1. Retry the CREATE; ensure upstream checkpoints have progressed past the snapshot epoch.
2. Verify the upstream source/table is producing checkpoint barriers (check barrier lag metrics).
3. If reproducible, gather the snapshot_epoch from the message and file a bug — barrier bookkeeping is inconsistent.

if let Err(e) = create_job_result {
    if e.to_string().contains("missing lagging barriers") {
        // wait for upstream checkpoints to progress, then retry CREATE
    }
}

When it happens

Trigger: Creating a streaming job with direct log-store read starting from a snapshot epoch when no lagging checkpoint barrier at/preceding that snapshot epoch is available in the pending barrier set (resolve_since_timestamp_upstream_log_epochs).

Common situations: Upstream barriers not yet checkpointed past the snapshot epoch; race between snapshot creation and barrier arrival; bug or truncation in log-store epoch metadata.

Understand the failure class

Background: EmptyResultError / "no results found": when an API or scraper succeeds but returns zero rows — this error's family across 9 libraries.

Related errors

• Exchange executor should not have children!
• Iceberg metadata scan should not have input executors
• Iceberg metadata scan received a non-Iceberg connector
• Iceberg source should not have input executor!
• Chunk size can't be zero!

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