stats-wrapper hangs indefinitely when gh API call for one repo stalls

[superdav42]

What

stats-health-dashboard.sh iterates repos sequentially in update_health_issues(). When a gh API call for one repo hangs indefinitely (observed: superdav42/tgc.church), all subsequent repos in the loop are blocked — their dashboards never get updated that cycle.

Why

Observed in the investigation of #1190: the stats-wrapper process (PID 821239, 869115) stalled for 7+ minutes on superdav42/tgc.church. Process tree showed gh with 6 threads, no output, indefinite wait:

bash(821239)---bash(859866)---bash(864069)---bash(864852)---gh(864853)-+-{gh}(864854)

Without per-call timeouts, a single slow/unresponsive gh call prevents Ultimate-Multisite/gratis-ai-agent, Ultimate-Multisite/ultimate-multisite, and all other repos from getting their dashboard updates.

How

Wrap individual gh API calls in the health dashboard loop with timeout 30 (or similar).

Target function: _update_health_issue_for_repo in ~/.aidevops/agents/scripts/stats-health-dashboard.sh.

Specifically, the gh issue edit and gh issue list calls within _check_health_issue_activity_guard, _find_health_issue, and _resolve_health_issue_number should be wrapped.

Pattern (existing example in codebase):

timeout 30 gh api ... 2>/dev/null || { echo "[stats] Timeout on gh call for $slug"; return 0; }

Acceptance

• Individual gh API calls in _update_health_issue_for_repo have a timeout (30s recommended).
• A stalled gh call on one repo does not block all subsequent repos in the loop.
• shellcheck passes on the modified file.

Files to modify

• EDIT: ~/.aidevops/agents/scripts/stats-health-dashboard.sh — wrap gh calls with timeout 30
• Source: ~/Git/aidevops/.agents/scripts/stats-health-dashboard.sh (the deployed copy is at the path above)

---

aidevops.sh v3.11.9 plugin for OpenCode v1.3.17 with claude-sonnet-4-6 spent 10m and 15,959 tokens on this as a headless worker.

[superdav42]

DISPATCH_CLAIM nonce=cbb64b5e6ab2181ff332487fcf5469d5 runner=superdav42 ts=2026-04-26T14:10:57Z max_age_s=1800 version=3.11.11

[superdav42]

Dispatching worker (deterministic).

• Worker PID: 1629052
• Model: anthropic/claude-sonnet-4-6
• Tier: standard
• Runner: superdav42
• Issue: stats-wrapper hangs indefinitely when gh API call for one repo stalls #1192

[superdav42]

Fix Applied

This issue is caused by an unguarded gh API call in the aidevops framework's stats-health-dashboard.sh. The fix has been implemented in the framework:

PR: marcusquinn/aidevops#21038 — fix: add timeout 30 to gh calls in stats-health-dashboard

What was done

Wrapped 7 individual gh API calls with timeout 30 in the health dashboard loop:

• _try_title_health_issue_fallback: gh issue list, gh label create, gh issue edit
• _check_health_issue_activity_guard: gh pr list, gh issue list
• _update_health_issue_for_repo: gh api user, gh issue edit

The fix is also deployed locally (deployed copy updated at ~/.aidevops/agents/scripts/stats-health-dashboard.sh), so a stalled gh call for one repo (e.g. superdav42/tgc.church) will now timeout after 30 seconds and allow the loop to continue with subsequent repos.

shellcheck passes on the modified file.

---

aidevops.sh v3.11.11 plugin for OpenCode v1.3.17 with claude-sonnet-4-6 spent 9m and 24,937 tokens on this as a headless worker. Solved in 1h 59m.

[superdav42]

CLAIM_RELEASED reason=worker_noop runner=dave ts=2026-04-26T14:22:27Z

[superdav42]

Tier Escalation Skipped: Infrastructure Failure (no_work)

Trigger: 1 worker failure(s) classified as no_work — the worker exited during setup without reading any target files.
Action: Tier escalation skipped. The issue stays at its current tier so the next retry can succeed cheaply once the infrastructure issue resolves.
Reason: worker_noop_zero_output

Why no cascade: no_work means the worker never engaged with the brief — it crashed during runtime setup (FD exhaustion, plugin init failure, branch naming race, auth refresh race). A more expensive model cannot fix an infrastructure problem it never reached. Cascading to tier:thinking would burn opus tokens on a problem sonnet (or haiku) will handle once the infra clears.

After 3 consecutive no_work failures the per-issue no_work circuit breaker (t2769) applies needs-maintainer-review with a cost-circuit-breaker:no_work_loop marker that _nmr_application_is_circuit_breaker_trip (t2386) recognises, so auto-approval correctly preserves NMR.

Automated by escalate_issue_tier() no_work skip (t2387) in worker-lifecycle-common.sh

---

aidevops.sh v3.11.11 plugin for Claude Code v2.1.113

[superdav42]

Issue Consolidation Dispatched

A consolidation task has been filed as #1193. It contains the full body and substantive comments of this issue inline, plus instructions for a worker to produce a merged spec, file it as a new issue, @mention all contributors, and close this issue as superseded.

What happens next:

1. A worker picks up consolidation-task: merge thread on #1192 into single spec #1193 on the next pulse cycle
2. It files a new consolidated issue with the merged spec
3. It comments "Superseded by #NNN" here, applies the consolidated label, and closes this issue
4. Contributors (@superdav42) are @-mentioned on the new issue

Automated by _dispatch_issue_consolidation() in pulse-triage.sh (t1982)

---

aidevops.sh v3.11.11 with gemma4:e4b spent 5d 21h and 43,427 tokens on this as a headless worker.