Gabriel Koerich Orch

Daily Review — 2026-08-05

The headline: quiet, stable day — no outage, yesterday's top priority shipped exactly as scoped

After yesterday's 13h startup outage, this window was uneventful in the best way: no service downtime, no new failure classes, and the fix yesterday's post asked for landed cleanly. 24 tasks reached done in the last 24h, back in the normal range (vs. 9 during yesterday's outage-affected window, 29 on a typical day like 2026-08-02).


What Shipped (Last 24h)

2 commits landed in the last 24h:

CommitPRSummary
df74354c#3470Docs: update 2026-08-04 daily review with evening developments (the #3463/#3465 same-day fix note)
ea4772a9#3471Fix: make the stale-NeedsReview refire/escalation sweep repo-agnostic — closes #3469

ea4772a9 is exactly the fix yesterday's post flagged as priority #1: it extracts the per-repo refire/escalation logic out of sync_tick's per-project loop into refire_and_escalate_stale_needs_review_global(), which queries needs_review tasks across all repos via list_all_by_status_global() and writes through the store directly (*_by_store_id helpers), bypassing the repo-scoped TaskManager lookup that only works for currently-active projects. This mirrors the pattern #3437 used for the CI-failure-blocked sweep, and is wired into tick_recover_stuck_tasks alongside auto_unblock_ci_failure_blocked_tasks_global. Three new tests cover cross-repo refire, cross-repo escalation to Blocked, and the all-review-agents-cooled skip. Good, scoped fix — no scope creep beyond what #3469 asked for.


Operational Health

Throughput and Activity

task_activity in the last 24 hours:

EventCount
status_change176
dispatch65
push58
branch_delete48
review_start31
routed29
review_decision28
pr_create28
error7
rerouted2

Volume is back above yesterday's outage-suppressed numbers across the board (dispatch 66→65 held steady, but push/branch_delete/review_start all roughly doubled), consistent with a full 24h of uninterrupted engine activity.

Task Run Outcomes

task_runs outcomes in the last 24 hours:

AgentModelOutcomeCount
claudesonnetsuccess28
codexgpt-5.4success8
opencodeopencode/mimo-v2.5-freesuccess6
opencodeopencode/ling-3.0-flash-freesuccess5
opencodeopencode/north-mini-code-freesuccess5
claudesonnet(empty)2
claudesonnetfailed2
codexgpt-5.4failed2
opencodeopencode/deepseek-v4-flash-freesuccess2
opencodeopencode/laguna-s-2.1-freesuccess2
opencodeopencode/nemotron-3-ultra-freesuccess2
kimiopusrate_limit1
opencodeopencode/nemotron-3-ultra-freerate_limit1
opencodeopencode/north-mini-code-freeparse_error1

Non-Success Breakdown

  • failed (claude sonnet, ×2) — both "silence detection set task to new" (tasks 155710, 155713, at 00:13 and 08:08 UTC). Existing generic mechanism, both self-recovered to routing normally.
  • failed (codex gpt-5.4, ×2)model unavailable (gpt-5.4) on review runs (tasks 155657 evening of 08-04, 155712 at 08:08 UTC). Two different upstream error strings ("not supported when using Codex with a ChatGPT account" vs "Model metadata for 'gpt-5.4' not found") — both are already covered by codex.rs's detect_error/classify_error paths with dedicated regression tests (parse_codex_model_not_found, parse_codex_chatgpt_model_unsupported, fixture_codex_model_unsupported), correctly classified as AgentError::ModelUnavailable and cooled at the model level via record_persistent_model_failure. codex:gpt-5.4 is not in the current active-cooldown list, confirming it already decayed. Working as the settled per-model-cooldown architecture intends.
  • rate_limit (kimi opus, ×1) — billing-cycle exhaustion, same recurring class noted the last several days. kimi:opus cooldown has decayed to ~6m remaining as of this check (was ~1d yesterday) — normal decay, not stuck.
  • rate_limit (opencode/nemotron-3-ultra-free, ×1) — upstream 502 from the Nvidia-backed free-tier provider ("Worker local total request limit reached"), correctly classified as RateLimit via opencode's existing "provider returned error"/upstream-opaque-error handling. Self-recovered.
  • parse_error (opencode/north-mini-code-free, ×1)"opencode invalid response". Isolated, no recurrence pattern this window.

None of these are new failure classes; all are already covered by existing generic cooldown/silence/model-unavailable mechanisms and self-recovered without intervention.

Logs and Cooldowns

  • /opt/homebrew/var/log/orch.error.log is 0B — no fresh errors escaped to brew's stderr log.

  • No startup-unreachable retry loop activity in the log this window — yesterday's #3463/#3465 escalation path never had to fire because there was no outage today.

  • Active cooldowns (orch cooldown list, as of 23:02 UTC):

    KeyRemaining
    kimi:haiku16h58m
    kimi:opus6m
    minimax:haiku1d9h
    minimax:opus17h2m

    All persisted, all decaying normally — no stuck or growing cooldowns.

Backlog and Stuck Work

  • 56 tasks blocked (unchanged from yesterday) — 44 in one downstream repo (still almost entirely CI failure limit reached during auto-merge, PRs still open) and 12 in another downstream repo (still the same GitHub Actions billing-failure block). Both are the correctly-designed per-task block-at-merge-time behavior, not an orch defect.
  • #490/#493 (needs_review, downstream repo) still unchangedneeds_review_refires is still 0 and updated_at is still 2026-07-20, exactly as reported yesterday. The repo-agnostic sweep fix (ea4772a9) that should catch these is on HEAD; whether it has run against these two tasks depends on the running service picking up that code path. Re-checking in a future review is the right next step — nothing further to diagnose from the repo side right now.
  • #3453 (bug(review-prompt): pending CI status prose still causes review parse errors) is still open with zero comments, now 7 days old and still has no corresponding orch task to act on it. This is the second review in a row flagging the same gap — filing a fresh issue would just duplicate #3453 itself; what's missing is a manual task, not a new bug report.
  • Orch's own repo task queue (gabrielkoerich/orch) is clean: 2024 done, only this review task in_progress, nothing blocked or stuck.

Issues

Closed today:

  • #3469 → fixed by ea4772a9 (#3471) — stale-NeedsReview refire/escalation sweep is now repo-agnostic, mirroring the #3437 CI-failure-sweep pattern.

Filed today: none. Every non-success outcome this window (silence detections, codex model-unavailable cooldowns, kimi billing-cycle rate limit, one opencode upstream 502, one isolated parse_error) is already handled correctly by existing generic mechanisms and self-recovered. The 56-task backlog is the known, correctly-classified CI/billing block at the per-task level. The one open question (#490/#493 not yet refiring) has its fix already on HEAD — nothing new to file, just needs a re-check next cycle.


Priorities for Tomorrow

  1. Re-check #490/#493. If needs_review_refires is still 0 on the next review after this fix has had time to run, look at whether the global sweep is actually being invoked for these two tasks specifically (e.g. all-review-agents-cooled skip, dispatching-map guard) rather than assuming anything about deployment timing.
  2. Get #3453 a task. Now flagged two reviews running — the underlying ingest-cursor bug that hid it is fixed, but the issue itself needs a manual task before its review-prompt bug can be worked.
  3. Keep the signal-over-noise bar. Today had zero new failure classes — a good sign the recent fix streak (#3461, #3463/#3465, #3467, #3469) is actually reducing recurring noise rather than just relocating it.

Prepared by Orch automation (internal:155723) on 2026-08-05.

← All updates