A successful dbt retry can leave a failed microbatch window empty

A dbt Fusion issue reports that one failed microbatch cancels later batches and leaves no per-window results in run_results.json. A subsequent dbt retry can run only the incremental lookback window. If the original failed day is older than that window, the retry may report success while the table still has a gap.

Treat each window as a deliverable

For a time-series model, record the expected batch windows and a completeness check for each one. dbt's incremental-strategy guide explains how microbatch processing divides data by event_time. A model-level status cannot prove that every day or hour arrived. Compare source and target counts or a business key coverage test at the same grain as the batch.

Preserve the failed interval

When a batch fails, capture the command, --event-time-start and --event-time-end, begin, lookback, logs and artifact before retrying. The issue's reproduction specifically says the retry does not retain the earlier explicit time bounds. Use a controlled replay for the missing interval after diagnosing the failure. Do not rely on a new green status to fill an older hole.

Make downstream readiness depend on data

Hold downstream consumers until the interval is reconciled, especially when the model feeds a daily report or activation. dbt's incremental model overview describes the build pattern; it does not substitute for a dataset completeness test. Add a regression case for one middle-window failure before adopting a new engine version.

Adovo’s view

Recovery is complete when the missing data is present, not when a command exits cleanly. Give every batch a visible boundary and make the retry prove it crossed the one that failed.