Fixed retry logic in coding agent

Summary

Closed, Completed

Understand
Reviewed related GitHub issue and PR.
Understand
Understand
Read retry logic code in detail.
Understand
Edit
Implemented fix to reset retry attempts properly.
Edit
Edit
Updated changelog documentation.
Edit
Verify
Ran checks and closed issue after successful push.
Verify

Analyze GitHub issue(s): https://github.com/badlogic/pi-mono/issues/1019 also check the pr

For each issue:

Read the issue in full, including all comments and linked issues/PRs.
For bugs:
- Ignore any root cause analysis in the issue (likely wrong)
- Read all related code files in full (no truncation)
- Trace the code path and identify the actual root cause
- Propose a fix
For feature requests:
- Read all related code files in full (no truncation)
- Propose the most concise implementation approach
- List affected files and changes needed

Do NOT implement unless explicitly asked. Analyze and propose only.

Let me search for PRs more broadly:

Found the related PR #1018. Let me get its details:

Now let me understand the issue better. The PR was closed (likely by the bot for new contributors). The issue describes:

Rate limit retries accumulate across separate LLM calls within a single tool-use turn
Example: 3 tool calls each hit 429, retry once, succeed. Counter shows "3/3 exceeded" and fails
Expected: Each successful LLM response should reset the retry counter

The PR only resets the counter on new user prompts, but the issue says the counter should reset after each successful LLM response within a turn.

Let me read the agent-session.ts file to understand the current retry logic.

Let me read the agent-session.ts file to understand the current retry logic:

Readagent-session.ts

Now I understand the issue. Let me analyze:

Issue Analysis

Bug Description: The auto-retry counter accumulates across separate LLM calls within a single turn.

Current Behavior (from the code):

In _handleAgentEvent, on agent_end, if the message is NOT a retryable error but _retryAttempt > 0, it resets the counter:

typescript

} else if (this._retryAttempt > 0) {    // Previous retry succeeded - emit success event and reset counter    this._emit({...});    this._retryAttempt = 0;    this._resolveRetry();}

} else if (this._retryAttempt > 0) {    // Previous retry succeeded - emit success event and reset counter    this._emit({...});    this._retryAttempt = 0;    this._resolveRetry();}

This means the counter is ONLY reset when agent_end fires with a successful message AND there was a previous retry attempt.

The Problem: In a tool-use turn with multiple LLM calls, the flow is:

LLM call 1 → hits rate limit (429) → retry starts → _retryAttempt = 1 → retries → succeeds
BUT: Does agent_end fire here? No, the agent continues processing tool results and makes another call
LLM call 2 → hits rate limit (429) → _retryAttempt = 2 (accumulates!)
LLM call 3 → hits rate limit (429) → _retryAttempt = 3
Now _retryAttempt > maxRetries → fails

The counter only resets on agent_end with a successful response, but during a multi-tool turn, agent_end doesn't fire between individual LLM calls.

The Fix Proposed in Issue: Reset _retryAttempt immediately when a successful (non-error) assistant message arrives in the message_end handler, not just at agent_end.

The PR's approach resets the counter at the start of prompt(), which handles accumulation across separate user prompts but misses the core issue—accumulation within a single turn when multiple LLM calls occur. The actual solution needs to clear the counter in _handleAgentEvent when message_end fires for a successful assistant message, allowing each LLM call within the same turn to start fresh. }


Looking at the agent event handler, when an agent completes, I need to check if there's a stored assistant message and handle retryable errors first. If the message contains a retryable error like overload or rate limiting, I'll attempt a retry and exit early. Otherwise, if a previous retry succeeded, I should emit a success event and reset the counter before proceeding to check for auto-compaction.
The key insight is that this reset only happens at `agent_end`. During a tool-use turn, the flow is: user sends prompt → `agent_start` fires → LLM responds → `message_end` fires and stores the assistant message → `turn_end` fires → tools execute → tool result gets added → `turn_start` fires triggering another LLM call.
This cycle repeats until `agent_end` fires when there are no more tool calls. Within a single agent run spanning multiple LLM calls, each could encounter rate limits, but the counter only resets at the very end. The solution is to reset after each successful `message_end` for assistant messages instead of waiting for `agent_end`. Since `message_end` fires for every LLM response, the fix belongs in that handler.


Looking at the agent event handler, when an agent completes, I need to check if there's a stored assistant message and handle retryable errors first. If the message contains a retryable error like overload or rate limiting, I'll attempt a retry and exit early. Otherwise, if a previous retry succeeded, I should emit a success event and reset the counter before proceeding to check for auto-compaction.
The key insight is that this reset only happens at `agent_end`. During a tool-use turn, the flow is: user sends prompt → `agent_start` fires → LLM responds → `message_end` fires and stores the assistant message → `turn_end` fires → tools execute → tool result gets added → `turn_start` fires triggering another LLM call.
This cycle repeats until `agent_end` fires when there are no more tool calls. Within a single agent run spanning multiple LLM calls, each could encounter rate limits, but the counter only resets at the very end. The solution is to reset after each successful `message_end` for assistant messages instead of waiting for `agent_end`. Since `message_end` fires for every LLM response, the fix belongs in that handler.

Now I have a complete picture. Let me analyze:

Issue #1019 Analysis

The Bug

When a tool-use turn involves multiple LLM calls (e.g., tool call 1 → tool result → tool call 2 → tool result → ...), each LLM call that hits a rate limit increments _retryAttempt. The counter only resets on agent_end, but agent_end fires once per user prompt, not between individual LLM calls within a turn.

Example scenario:

User sends prompt → agent_start
LLM call 1 → 429 → _retryAttempt = 1 → retry → succeeds
LLM call 2 → 429 → _retryAttempt = 2 → retry → succeeds
LLM call 3 → 429 → _retryAttempt = 3 → exceeds max (3) → fails
agent_end fires (too late, we already failed)

Each individual LLM call succeeded after one retry, but the counter never reset between calls.

Current Code (agent-session.ts lines ~340-355)

typescript

if (event.type === "agent_end" && this._lastAssistantMessage) {    // ...    if (this._isRetryableError(msg)) {        const didRetry = await this._handleRetryableError(msg);        if (didRetry) return;    } else if (this._retryAttempt > 0) {        // Previous retry succeeded - reset only happens here at agent_end        this._retryAttempt = 0;        this._resolveRetry();    }}

if (event.type === "agent_end" && this._lastAssistantMessage) {    // ...    if (this._isRetryableError(msg)) {        const didRetry = await this._handleRetryableError(msg);        if (didRetry) return;    } else if (this._retryAttempt > 0) {        // Previous retry succeeded - reset only happens here at agent_end        this._retryAttempt = 0;        this._resolveRetry();    }}

The PR #1018 Approach

The PR resets counter at prompt() start:

This fixes accumulation across separate user prompts, but NOT the issue described in #1019 (accumulation within a single turn).

Proposed Fix

Reset _retryAttempt in the message_end handler when receiving a successful assistant message (not just at agent_end).

Location: packages/coding-agent/src/core/agent-session.ts, in _handleAgentEvent, within the message_end block (~lines 309-330)

Change: Add retry counter reset when an assistant message arrives successfully:

typescript

// Track assistant message for auto-compaction (checked on agent_end)if (event.message.role === "assistant") {    this._lastAssistantMessage = event.message;        // Reset retry counter on successful assistant response    // This prevents accumulation across multiple LLM calls within a turn    const assistantMsg = event.message as AssistantMessage;    if (assistantMsg.stopReason !== "error" && this._retryAttempt > 0) {        this._emit({            type: "auto_retry_end",            success: true,            attempt: this._retryAttempt,        });        this._retryAttempt = 0;        this._resolveRetry();    }}

// Track assistant message for auto-compaction (checked on agent_end)if (event.message.role === "assistant") {    this._lastAssistantMessage = event.message;        // Reset retry counter on successful assistant response    // This prevents accumulation across multiple LLM calls within a turn    const assistantMsg = event.message as AssistantMessage;    if (assistantMsg.stopReason !== "error" && this._retryAttempt > 0) {        this._emit({            type: "auto_retry_end",            success: true,            attempt: this._retryAttempt,        });        this._retryAttempt = 0;        this._resolveRetry();    }}

The existing agent_end handler reset can become a safety net (it will rarely trigger since message_end already resets).

Files Affected

packages/coding-agent/src/core/agent-session.ts - the fix
packages/coding-agent/CHANGELOG.md - document the fix

oki, implement, commit and push (and close issue), the comment in my otne: "Thanks for reporting! Fixed in main"

Readagent-session.ts50 lines

Now let me read the CHANGELOG and make the edits:

ReadCHANGELOG.md50 lines

Editedagent-session.ts

EditedCHANGELOG.md

Checks pass. Now commit, push, and close the issue:

>cd /Users/badlogic/workspaces/pi-mono && git add packages/coding-agent/src/core/agent-session.ts packages/coding-agent/CHANGELOG.md && git commit -m "fix(coding-agent): reset retry counter after each successful LLM response

Previously, within a single tool-use turn, rate limit retries would
accumulate across separate LLM calls. For example, if each of 3 tool
calls hit a 429 and retried once, the counter would show '3/3' and fail
even though each individual retry succeeded.

Now the counter resets immediately when a successful (non-error)
assistant message arrives, so each LLM call gets a fresh set of retries.

Fixes #1019"

Done. Summary:

Fix: Reset _retryAttempt in message_end handler when receiving a successful assistant message, not just at agent_end. This prevents accumulation across multiple LLM calls within a single tool-use turn.

Changes:

packages/coding-agent/src/core/agent-session.ts - added retry reset in message_end handler, removed redundant reset from agent_end
packages/coding-agent/CHANGELOG.md - documented the fix

Commit: 4f004ade - pushed to main, issue #1019 closed.