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:
| Commit | PR | Summary |
|---|---|---|
df74354c | #3470 | Docs: update 2026-08-04 daily review with evening developments (the #3463/#3465 same-day fix note) |
ea4772a9 | #3471 | Fix: 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:
| Event | Count |
|---|---|
status_change | 176 |
dispatch | 65 |
push | 58 |
branch_delete | 48 |
review_start | 31 |
routed | 29 |
review_decision | 28 |
pr_create | 28 |
error | 7 |
rerouted | 2 |
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:
| Agent | Model | Outcome | Count |
|---|---|---|---|
| claude | sonnet | success | 28 |
| codex | gpt-5.4 | success | 8 |
| opencode | opencode/mimo-v2.5-free | success | 6 |
| opencode | opencode/ling-3.0-flash-free | success | 5 |
| opencode | opencode/north-mini-code-free | success | 5 |
| claude | sonnet | (empty) | 2 |
| claude | sonnet | failed | 2 |
| codex | gpt-5.4 | failed | 2 |
| opencode | opencode/deepseek-v4-flash-free | success | 2 |
| opencode | opencode/laguna-s-2.1-free | success | 2 |
| opencode | opencode/nemotron-3-ultra-free | success | 2 |
| kimi | opus | rate_limit | 1 |
| opencode | opencode/nemotron-3-ultra-free | rate_limit | 1 |
| opencode | opencode/north-mini-code-free | parse_error | 1 |
Non-Success Breakdown
failed(claude sonnet, ×2) — both"silence detection set task to new"(tasks155710,155713, at00:13and08:08UTC). Existing generic mechanism, both self-recovered to routing normally.failed(codex gpt-5.4, ×2) —model unavailable (gpt-5.4)on review runs (tasks155657evening of 08-04,155712at08:08UTC). 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 bycodex.rs'sdetect_error/classify_errorpaths with dedicated regression tests (parse_codex_model_not_found,parse_codex_chatgpt_model_unsupported,fixture_codex_model_unsupported), correctly classified asAgentError::ModelUnavailableand cooled at the model level viarecord_persistent_model_failure.codex:gpt-5.4is 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:opuscooldown has decayed to ~6m remaining as of this check (was ~1d yesterday) — normal decay, not stuck.rate_limit(opencode/nemotron-3-ultra-free, ×1) — upstream502from the Nvidia-backed free-tier provider ("Worker local total request limit reached"), correctly classified asRateLimitvia 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.logis0B— 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):Key Remaining 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 entirelyCI 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 unchanged —needs_review_refiresis still0andupdated_atis still2026-07-20, exactly as reported yesterday. The repo-agnostic sweep fix (ea4772a9) that should catch these is onHEAD; 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#3453itself; what's missing is a manual task, not a new bug report.- Orch's own repo task queue (
gabrielkoerich/orch) is clean: 2024done, only this review taskin_progress, nothing blocked or stuck.
Issues
Closed today:
- #3469 → fixed by
ea4772a9(#3471) — stale-NeedsReviewrefire/escalation sweep is now repo-agnostic, mirroring the#3437CI-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
- Re-check
#490/#493. Ifneeds_review_refiresis still0on 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. - Get
#3453a 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. - 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.