Skip to content

fix(errors): let a lagging error-tick cursor cross quiet stretches in one tick - #1277

Closed
JeremyFunk wants to merge 2 commits into
mainfrom
fix/error-tick-idle-cursor-catchup
Closed

JeremyFunk wants to merge 2 commits into
mainfrom
fix/error-tick-idle-cursor-catchup

fix(errors): first-match look-ahead query, fall back to the claimed w…

84365d9
Select commit
Loading
Failed to load commit list.
Maple Review Bot / Maple / review succeeded Oct 6, 2026 in 2m 53s

Confidence 4/5 · No issues found

🟢 Confidence 4/5 · likely safe to merge
A fast-forwarded window relabels resolvedAt/event timestamps to the later window end (error-tick-persistence.ts:862), a disclosed tradeoff no test pins.
quality 100/100 · no findings · tests covered · risk medium · 3/3 new units observable

Lets a lagging error-tick cursor cross a quiet stretch in one tick: when the claimed window is empty and the cursor is behind the cutoff, it extends the window to the next minute that has errors, or to the cutoff. The look-ahead reads the same rollup with the same predicate as the tick scan, so it cannot skip errors; safe to merge.

  • errorTickNextActivityQuery returns the earliest error minute in a range
  • processOrg extends an empty claimed window to the next activity minute or the cutoff
  • Skips the look-ahead after a row-cap split and during bootstrap
  • Tick span gains windowFastForwarded
What was checked
  • Look-ahead cannot skip errors: identical OrgId/Minute predicate as the scan (queries/errors.ts:1174 vs :1157), and the extended range is applied as empty only when the scan already returned no…
  • A leap to the cutoff is still bounded by cutoffMs, so late-arriving minutes can escape it no more than a steady-state tick already tolerates
  • Steady state never pays the extra read: windowEndMs already equals the cutoff (ErrorsService.ts:1095)
Observability coverage: 3 of 3 changes observable
Change Kind Observable Evidence
Error-tick window look-ahead (errorTickNextActivityQuery read in processOrg) outbound warehouse read yes goes through the shared executor Client span (execution/executor.ts:413) annotated with db.system.name, peer.service, query.context=errorTickNextActivity, query.profile
Catch-up decision on the existing error-tick cron in-process state change yes windowFastForwarded annotated on the tick span (ErrorsService.ts:1249); the look-ahead failure path logs Effect.logWarning with annotateLogs
New query builder errorTickNextActivityQuery warehouse query definition yes covered by the executor span above; added to the benchmark catalog and SQL baseline

84365d9 · Updated on every push. Reply "won't fix" to dismiss a finding, or mention @maple-review-bot to ask about one.