Skip to content

fix(claude): move to @col/a2a-claude@0.2.1-beta.5 - #10

Merged
col merged 1 commit into
mainfrom
fix/a2a-claude-beta-5
Aug 11, 2026
Merged

fix(claude): move to @col/a2a-claude@0.2.1-beta.5#10
col merged 1 commit into
mainfrom
fix/a2a-claude-beta-5

Conversation

@col

@col col commented Aug 11, 2026

Copy link
Copy Markdown
Owner

Moves the Claude wrapper to 0.2.1-beta.5. Pin bump only — Throng set neither of the affected config blocks.

Rate limits fail the task again, correcting v0.1.11

v0.1.11 ended a rate-limited turn as a non-terminal input-required task, on the reasoning that holding the task open let a client continue the same conversation. That reasoning did not hold:

  • The interrupted turn cannot resume. A follow-up on the open task sends the new user message as a fresh prompt — exactly what a new task would have sent. There is no replay or continue-previous-turn path.
  • Continuity never came from the task state. It comes from the contextId → Claude session mapping, which is indifferent to how a task ended.
  • input-required says the wrong thing. It means the agent lacks information; a rate limit lacks quota, and nothing a client sends unblocks it — only elapsed time. A client with generic input-required handling would prompt a human for input nobody wants.
  • Publishing a non-terminal state alongside final: true was inconsistent.

A rate limit now always publishes failed. The rateLimit.taskState option is removed rather than re-defaulted, so this is no longer configurable; Throng never set it. The message now points at the contextId rather than the closed task and still carries the structured retry metadata (reason, rateLimitType, resetsAt, resetsAtIso, utilization, plus errorCode / canPurchaseCredits when reported). features.emitRateLimitEvents is unchanged — the SDK's in-turn retries remain visible as rate_limit sideband events.

Net effect: a rate-limited turn looks the way it did before 0.1.11 — a terminal failed task — but is now distinguishable from a generic error, since the status names the limit and the metadata says when it resets.

session.cleanupInterval defaults to 0

Only consulted when ttl > 0, and ttl has defaulted to 0 since the last release, so the old 300_000 was dead configuration that read as if it swept something. Both disabled states now log at startup. No behaviour change for Throng, which sets neither.

Verification

npm run build, npm run typecheck, npm test all pass locally (7/7 turbo tasks, 6/6 tests).

🤖 Generated with Claude Code

https://claude.ai/code/session_013hanN6ZyX6tDZEsxGZpFto

Corrects the rate-limit behaviour shipped in v0.1.11, where a rate-limited turn
ended as a non-terminal input-required task on the reasoning that holding the
task open let a client continue the conversation.

That reasoning did not hold. The interrupted turn cannot resume — a follow-up on
the open task sends the new user message as a fresh prompt, exactly what a new
task would send — and continuity comes from the contextId -> Claude session
mapping, not the task state. input-required also means the agent lacks
information, whereas a rate limit lacks quota: nothing a client sends unblocks
it, only elapsed time, so generic input-required handling would prompt a human
for input nobody wants.

A rate limit now always publishes failed, with the message pointing at the
contextId and still carrying the structured retry metadata. The rateLimit
.taskState option is removed rather than re-defaulted; Throng never set it.

Also: session.cleanupInterval now defaults to 0 to match ttl, which has been 0
since the last release — the old 300s default was dead configuration.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013hanN6ZyX6tDZEsxGZpFto
@col
col merged commit d920dad into main Aug 11, 2026
1 check passed
@col
col deleted the fix/a2a-claude-beta-5 branch August 11, 2026 08:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant