feat: add listAgents and make ensureAgent idempotent at the agent cap#41
Merged
Conversation
ensureAgent is documented as idempotent ("returns normally if it already exists"), but it broke at the project's agent cap. The server evaluates the agent quota before the identifier-uniqueness check, so re-creating an existing identifier while at the cap returned 403 (quota) instead of the 409 (conflict) that ensureAgent treats as success -- so ensureAgent threw even though the agent already existed.
On a 403, ensureAgent now confirms whether the agent already exists (via a new listAgents() call) and, if so, resolves with created: false; a genuine quota error (agent does not exist) still surfaces. The happy path is unchanged -- the extra lookup only runs on a 403.
Also adds a public listAgents() method and Agent type.
Fixes #40
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Companion server-side root-cause fix: onecli/onecli-cloud#550. That PR makes the API return the canonical 409 at the cap; this PR hardens the SDK so |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ensureAgentis documented as idempotent — "Creates it if missing, returns normally if it already exists." It broke once a project hit its agent cap, even when the target agent already existed and the call should have been a no-op.Root cause: the server evaluates the agent-count quota before the identifier-uniqueness check, so re-creating an existing identifier while at the cap returns 403 (quota) instead of the 409 (conflict) that
ensureAgenttreats as success.ensureAgentonly handled409, so the403propagated. The root cause is fixed server-side in the companiononecli-cloudPR; this change hardens the SDK so the documented contract holds regardless of server version.What this does
ensureAgent— on a403, confirms whether the agent already exists and, if so, resolves withcreated: false; a genuine quota error (agent doesn't exist) still throws. The happy path is unchanged — the extra lookup only runs on a403.listAgents()— new public method (GET /v1/agents) +Agenttype. The fallback needs it, and it's a useful primitive the SDK was missing.Testing
pnpm typecheck,pnpm build,pnpm test— all green (74 tests).+7tests:listAgents(happy / 4xx / network) and theensureAgent403branches (exists →created: false; absent → throws403; existence-check itself fails → throws the original403).Fixes #40
🤖 Generated with Claude Code