sqb recall query "SELECT substr(invocation_started_at, 1, 16) AS run, outcome, - violation_count FROM audit_results WHERE audit_name = 'revenue_is_non_negative' - ORDER BY run DESC LIMIT 3" -run | outcome | violation_count -2026-10-20T00:01 | warn | 1 -2026-10-20T00:00 | pass | 0 -2026-10-19T23:59 | pass | 0 +sqb recall query "SELECT substr(a.invocation_started_at, 1, 16) AS run, + a.outcome, a.violation_count, i.status, i.exit_code FROM audit_results a + JOIN invocations i USING (invocation_id) + WHERE a.audit_name = 'revenue_is_non_negative' ORDER BY run DESC LIMIT 3" +run | outcome | violation_count | status | exit_code +2026-10-20T00:01 | warn | 1 | completed | 0 +2026-10-20T00:00 | pass | 0 | completed | 0 +2026-10-19T23:59 | pass | 0 | completed | 0 sqb recall output last --tail 4 daily_revenue audit revenue_is_non_negative returned 1 row ✓ Completed with warnings PASS=89 WARN=1 FAIL=0 … -sqb recall query --backend warehouse "SELECT r.revenue_date, r.total_revenue_cents, - p.payment_id, p.amount_cents FROM prod.daily_revenue r JOIN prod.stg_payments p - ON CAST(p.paid_at AS DATE) = r.revenue_date WHERE p.amount_cents < 0" -revenue_date | total_revenue_cents | payment_id | amount_cents -2026-04-03 | -1250 | 9 | -2200+sqb recall query --backend warehouse "SELECT payment_id, order_id, amount_cents, paid_at + FROM prod.stg_payments WHERE amount_cents < 0" +payment_id | order_id | amount_cents | paid_at +9 | 8 | -2200 | 2026-04-03 15:42:00
Real output from SQLBuild's example project, trimmed to the relevant lines. During a migration the old table is never modified, archives can be renamed back until they expire, and every move is recorded. - In step 09 the audit started warning on the latest run, the build still finished, and the bad - row is still in prod: a refund recorded as a negative payment. Three queries, no log digging. + In step 09 the audit started warning on the latest run, the build still exited 0, and the cause + is still in prod: a refund recorded as a negative payment. Three commands, no log digging. History stays in a SQLite file in your project, or in ClickHouse for a team. No service, no account, no paid tier. How migrations work · diff --git a/website/src/content/docs/docs/concepts/observability/recall.mdx b/website/src/content/docs/docs/concepts/observability/recall.mdx index d0ac97d210..3d5c4f9d53 100644 --- a/website/src/content/docs/docs/concepts/observability/recall.mdx +++ b/website/src/content/docs/docs/concepts/observability/recall.mdx @@ -13,25 +13,28 @@ The waffle shop example's `daily_revenue` model has an audit, `revenue_is_non_ne severity. One night the payments feed starts recording a refund as a negative payment. The unit tests still pass, because they run on mocked data. The build finishes with a warning that nobody reads. -The next morning, ask when the audit started failing: +The next morning, ask when the audit started failing, and what each of those builds reported: ```bash sqb recall query --format table \ - "SELECT invocation_started_at AS run, outcome, violation_count FROM audit_results - WHERE audit_name = 'revenue_is_non_negative' ORDER BY run DESC LIMIT 3" + "SELECT a.invocation_started_at AS run, a.outcome, a.violation_count, i.status, i.exit_code + FROM audit_results a JOIN invocations i USING (invocation_id) + WHERE a.audit_name = 'revenue_is_non_negative' ORDER BY run DESC LIMIT 3" ``` ``` -run | outcome | violation_count ---------------------------- | ------- | --------------- -2026-10-20T00:01:44.784683Z | warn | 1 -2026-10-20T00:00:34.652468Z | pass | 0 -2026-10-19T23:59:23.827831Z | pass | 0 +run | outcome | violation_count | status | exit_code +--------------------------- | ------- | --------------- | --------- | --------- +2026-10-20T00:01:44.784683Z | warn | 1 | completed | 0 +2026-10-20T00:00:34.652468Z | pass | 0 | completed | 0 +2026-10-19T23:59:23.827831Z | pass | 0 | completed | 0 3 rows ``` -See what that run printed, exactly as the scheduler saw it: +The audit started warning on the latest build, and that build still exited 0, so nothing alerted. + +See what that build printed, exactly as the scheduler saw it: ```bash sqb recall output last --tail 4 @@ -44,26 +47,24 @@ sqb recall output last --tail 4 ✓ Completed with warnings PASS=89 WARN=1 FAIL=0 INSUFFICIENT=0 SKIP=0 TOTAL=90 (3.08s) ``` -Then check what is true in the warehouse now, with the same command: +Then check what is true in the warehouse now, with `sqb recall query` again: ```bash sqb recall query --backend warehouse --format table \ - "SELECT r.revenue_date, r.total_revenue_cents, p.payment_id, p.amount_cents - FROM prod.daily_revenue r JOIN prod.stg_payments p - ON CAST(p.paid_at AS DATE) = r.revenue_date - WHERE p.amount_cents < 0" + "SELECT payment_id, order_id, amount_cents, paid_at FROM prod.stg_payments WHERE amount_cents < 0" ``` ``` -revenue_date | total_revenue_cents | payment_id | amount_cents ------------- | ------------------- | ---------- | ------------ -2026-04-03 | -1250 | 9 | -2200 +payment_id | order_id | amount_cents | paid_at +---------- | -------- | ------------ | ------------------- +9 | 8 | -2200 | 2026-04-03 15:42:00 1 row ``` -The bad row is still in prod, and payment 9 explains it. A coding agent can follow the same steps: -every answer is a SQL query over the [views](#querying-history), with the same output in `--json`. +Payment 9 is a refund recorded as a negative payment, and it is still in prod. A coding agent can +follow the same steps: the history is SQL over the [views](#querying-history), and every query can +return `--json`. ## What is recorded