[Bug] v0.8.0: multi-hour silent blocking inside a single anthropic-messages call; concurrent processes resume within the same second

[claudegoogl-sudo]

Affected area

AI providers and models
Coding agent and CLI

What happened?

prime-agent CLI v0.8.0 can block silently for multiple hours inside a single anthropic-messages provider call. On one Linux host we observed several concurrent CLI processes stall at the same time: each emitted its turn_start event and then produced no further output — no message_end, no progress event, no error — for 3–5 hours. All of the stalled processes resumed within the same second, which points to blocking on a shared usage-window / rate-limit gate rather than per-request retries. In one case a token 401 error surfaced only at the tail, after the long wait had already ended.

Practical impact: while blocked, the CLI gives the caller no signal at all. There is no way to distinguish a wedged process from a legitimate provider wait, no hook to apply our own timeout policy, and hours of wall-clock time are lost silently.

Steps to reproduce

We do not have a minimal deterministic reproducer — the trigger appears to be provider-side usage-window exhaustion — but the observed sequence is:

1. Run several prime-agent CLI sessions concurrently on one host, with account usage near its usage-window limit.
2. Each session reaches a provider call; turn_start is emitted, then output stops.
3. Observe complete silence (no message_end, no error, no progress event) for 3–5 hours across all processes.
4. Observe all processes resume within the same second, consistent with a shared usage-window reset.
5. In one observed case, a 401 (token error) surfaced only after the wait, at the tail of the request.

Expected behavior

1. A bounded per-inference-call timeout that emits a diagnostic event and then retries or fails — never an unbounded silent block.
2. Periodic progress events while blocked on a known provider wait (e.g. a "waiting on provider usage window until " status), so callers can see the CLI is alive.
3. Proactive token refresh that fires even while a request is blocked, so a long wait does not end in a tail 401.

Actual behavior

Between turn_start and the eventual resume there is complete silence for 3–5 hours: no progress event, no diagnostic, no timeout. All concurrently blocked processes resume within the same second. The 401 appears only after the wait completes.

Prime Agent version

0.8.0

Installation method

npm package

Operating system

Linux

Operating system version

Ubuntu 24.04.4 LTS (kernel 6.8.0-138-generic)

CPU architecture

x86_64 / amd64

Shell and terminal

bash 5.2.21, non-interactive headless environment (CLI driven by automation, no terminal emulator)

Additional context

The synchronized resume is the strongest signal we have: independent processes with per-request exponential backoff would drift apart, but all processes here resumed within the same second, which means they were parked on the same shared wait — consistent with a shared usage-window gate.

The three requests above are about observability and boundedness, not about changing rate-limit behavior. Even a correct, vendor-intended gate wait should be visible and bounded to the caller: emit a diagnostic when entering the wait, emit periodic progress, and enforce a bounded maximum so the caller can retry or fail cleanly.

[awhite0030]

Investigated this report and produced a candidate fix, validated on a fork of this repository.

Root cause, fix and validation from the working notes:

Root cause: The underlying ReadableStream.getReader().read() in Node's fetch implementation blocks indefinitely and does not respect the provided AbortSignal for timeouts during an anthropic-messages stream.
Fix: Wrapped reader.read() inside iterateSseMessages in a Promise.race against a custom abort promise that listens to the AbortSignal. To avoid UnhandledPromiseRejection crashes when the slower promise eventually rejects, .catch(() => {}) is safely attached to both promises.
Validation: Wrote a regression test in packages/ai/test/suite/regressions/anthropic-abort-hang.test.ts that mocks a hanging provider response and ensures the stream gracefully emits an abort error within 1 second. Tests pass successfully.
Upstream discussion: #2093

Diff: awhite0030/prime-agent@main...jules-5005970707589739706-fe90f932
Full pull request: awhite0030#62

The change passes npm run check and the focused regression tests against current main. If a fix for this is still wanted, I can open a pull request.