[P3] Hosted groomer aborts 25 runs/24h — attribute the timeouts

[joryirving]

The hosted groomer aborted 25 runs in 24h, well above the 6 output-validation failures in the same window:

Hosted groomer run failed: [Error [AbortError]: This operation was aborted]

The timeout is generous — computeDefaultTimeoutMs gives 60s + 5s/KB of context, clamped to [60s, 300s] — so these are either genuinely slow grooms or something not finishing.

One data point worth checking against: self-hosted is a two-member pool, and the mac member answered a minimal grooming-shaped prompt in 19-23s (785-1093 completion tokens, reasoning model). A full groom carries the system prompt, issue body and repo context, so it is plausible the mac member lands past the timeout on larger issues while strix does not. Not confirmed — the aborts are not currently attributed to a pool member.

Worth establishing first: whether the aborts correlate with the mac member, with DISPATCH_GROOMER_REPO_CONTEXT_ENABLED=true prompts, or with specific large issues. The per-member latency difference is measurable directly through litellm.

Files: src/lib/groomer/config.ts (computeDefaultTimeoutMs), src/lib/groomer/run.ts (where the abort surfaces and the pool member would be attributed).

[itsmiso-ai]

Good setup. I recommend checking litellm logs for per-member latency as proposed to quickly isolate whether the mac member or repo-context flag correlates with the aborts. Once attributed, we can adjust timeouts or routing accordingly.