## Summary
In the Python SDK, HTTP failures from the generated client escape
`except ComposioError`: `composio_client` has its own exception root,
unrelated to `composio.exceptions.ComposioError`. An invalid API key, a
429 or a 500 therefore bypasses a handler written against the SDK's base
error, while the TypeScript SDK covers the equivalent case (#4459).
Opened this so there's something concrete to look at alongside the
issue. Happy to rework it or close it if you'd prefer a different
approach.
Fixes#4537
## Changes
- `HttpClient` overrides `_make_status_error`, the single place the
generated client builds status errors, and returns each error as a
subclass of **both** the generated class and `ComposioError` (one cached
subclass per generated class).
- New `python/tests/test_client_errors.py` covering every mapped status
plus an unmapped one, class reuse, and the SDK's existing
`ToolNotFoundError` mapping.
I went with this rather than wrapping errors at call sites, which is
what I suggested on the issue, because it keeps every existing handler
working:
- `except ComposioError` now catches HTTP failures.
- `except composio_client.AuthenticationError` / `APIStatusError` still
work, with `status_code`, `response` and `body` unchanged.
- The SDK's own mappings are untouched: `get_raw_composio_tool_by_slug`
still raises `ToolNotFoundError` on 400/404 and re-raises other client
errors unchanged, per its docstring and `test_tool_retrieval_errors.py`.
The same holds for `TriggerTypeNotFound`.
- No call sites change, so every endpoint is covered, including ones
added later.
On relying on a private method: `_make_status_error` is the hook the
generated base client declares (`raise NotImplementedError()`) and calls
for every status error, and `HttpClient` already overrides
`_prepare_request` from the same base. `composio-client` is pinned
exactly, and the new tests run through a real `HttpClient`, so a
generator change that altered the hook would fail CI at the version bump
rather than silently regress.
Left alone:
- **Transport-level errors.** `APIConnectionError` and `APITimeoutError`
are raised by the base client without going through
`_make_status_error`, so an HTTP timeout still escapes `except
ComposioError`. (The issue said timeouts were already covered; that was
true only for the SDK's own `ComposioSDKTimeoutError` from
`wait_for_connection`, not for HTTP timeouts.) Happy to follow up if you
want those covered too.
- **The existing `composio.client.ComposioAPIError` alias** still points
at the generated `APIError`, unchanged. The name I floated on the issue
would have collided with it, and this approach doesn't need a new public
class.
## Type of change
- [x] Bug fix
- [ ] New feature
- [ ] Refactor/Chore
- [ ] Documentation
- [ ] Breaking change
## How Has This Been Tested?
`python/tests/test_client_errors.py` runs a real `HttpClient` against an
`httpx.MockTransport`. Each status (400, 401, 403, 404, 409, 422, 429,
500, and an unmapped 418) raises an error that is both a `ComposioError`
and the expected generated class, with `status_code` preserved. Without
the fix, 12 of the 13 new tests fail.
From `python/`, Python 3.12, `composio-client==1.43.0`:
```
$ pytest tests/ -q
2072 passed, 1 skipped
$ ruff check --config config/ruff.toml composio tests
All checks passed!
$ ruff format --config config/ruff.toml --check composio/client/__init__.py tests/test_client_errors.py
2 files already formatted
$ mypy --config-file config/mypy.ini composio
Success: no issues found in 58 source files
```
Live check against production with an invalid key:
```python
from composio import Composio
from composio.exceptions import ComposioError
try:
Composio(api_key="ak_invalid").create(user_id="u")
except ComposioError as e:
print(type(e), e.status_code)
```
On `next` this raises `composio_client.AuthenticationError`, which
escapes the handler. On this branch the handler catches it, and it is
still an `AuthenticationError` with status 401.
## Checklist
- [x] I have read the Code of Conduct and this PR adheres to it
- [x] I ran linters/tests locally and they passed
- [ ] I updated documentation as needed (no docs change; the public API
is unchanged)
- [x] I added tests or explain why not applicable
- [ ] I added a changeset if this change affects published packages
(Python-only change; CONTRIBUTING asks for changesets on published
TypeScript packages)
## Additional context
Found while integrating the Python SDK into
[Inferra](https://github.com/deepgori/inferra), where a GitHub-issue
filer caught `ComposioError` and missed the invalid-key path.
---------
Co-authored-by: jkomyno <alberto@composio.dev>
Co-authored-by: Alberto Schiabel <jkomyno@users.noreply.github.com>
Review follow-up to #3657 (squash-merged before these review fixes could
land on it). No behaviour change to the retry scoping itself — this
tightens correctness, docs, and test coverage around the
`without_retries` mechanism.
- **Correct the `without_retries` caching rationale.** The previous
docstring justified caching with "each clone creates a new `ContextVar`,
and dynamically-created `ContextVar`s are never garbage-collected." That
is false for this code path: `request_ctx` is only ever `.get()`, never
`.set()`, so it is reclaimed by refcounting on drop (measured: 500k
get-only clones leak ~0 KiB; the CPython leak only occurs with
`.set()`). Caching is kept because it avoids constructing a fresh
`HttpClient` on every `execute`/`proxy` (the hottest path) — the real,
stated justification now.
- **Preserve `_strict_response_validation` on the clone.** The
Stainless-generated `copy()` drops it, so the no-retry sibling silently
reverted to the default (`False`) even when the parent had it enabled.
The `copy()` override now threads it through `_extra_kwargs` alongside
`provider`, so the sibling differs from the parent only in
`max_retries`.
- **Document the scope boundary.** The `without_retries` docstring now
states that only `tools.execute` / `tools.proxy` are de-retried; other
non-idempotent writes (`auth_configs.create`/`update`/`delete`,
`mcp.update`/`delete`, `connected_accounts.delete`/`refresh`,
`link.create`) keep the default retries (most are naturally idempotent
on retry; the durable fix is backend idempotency keys).
- **Add regression coverage:** the clone preserves
`_strict_response_validation`, plus contract guards pinning the
Stainless `copy`/`_extra_kwargs`/`with_options` internals the override
relies on — so a `composio_client` regen that breaks the contract fails
as an obvious assertion rather than a cryptic `TypeError`.
- Minor: fix the `x-sdk-version` `"unknwon"` → `"unknown"` typo and
tighten `te.Self` typing on the cache field/property.
No changeset (Python-only change; changesets are TypeScript-only).
This PR:
- stops the Python SDK from silently retrying `tools.execute` and
`tools.proxy`, which are non-idempotent POST writes. The
Stainless-generated client retries POSTs by default (`max_retries=2`) on
read timeouts, 429, 5xx, and connection errors. A read timeout is unsafe
to retry — the request may already be in flight on the backend — so a
retry can duplicate the side effect, e.g. send an email twice. Reported
in https://github.com/ComposioHQ/composio/issues/3586
- routes both write paths through a new `client.without_retries` — a
cached, retry-disabled (`max_retries=0`) clone of the `HttpClient`.
Reads and lists keep the default retries, so resilience is unchanged for
idempotent calls
- overrides `HttpClient.copy()` to re-inject the required `provider`
keyword and re-aliases `with_options`, since the generated `copy()`
rebuilds via `self.__class__(...)` without `provider` — previously
`with_options(max_retries=0)` raised `TypeError` on the subclass
- caches the no-retry sibling instead of cloning per call: each clone
creates a new `ContextVar`, and dynamically-created `ContextVar`s are
never garbage-collected
- adds `tests/test_no_retry_writes.py`: writes hit the transport exactly
once on a retryable 5xx, reads still retry-then-succeed (proving the
scoping), and a regression guard for the `copy()` override
- interim fix only — the durable solution is idempotency keys, tracked
in https://github.com/ComposioHQ/composio/issues/3654 (gated on backend
support), which supersedes this once available
No changeset (Python-only change; changesets are TypeScript-only).
Python mirror of #3392 (TypeScript SDK). Same Apollo-side feature shipped
across four Hermes PRs (#9860, #9882, #9887 internal, #9902), now exposed
through @composio/* Python SDK wrappers.
Bumped composio-client 1.37.0 → 1.38.0 (the regenerated client published
by composio-base-py#66 — contains account_type + acl_config_for_shared on
LinkCreateParams, ConnectedAccountPatchParams, SessionLinkParams, the
retrieve response, and the list response item).
SDK changes:
- composio.connected_accounts.link() now accepts `account_type` and
`acl_config_for_shared`. Default behaviour (omit both) creates a
PRIVATE connection exactly as before.
- New composio.connected_accounts.update_acl(nanoid, *, allow_all_users,
allowed_user_ids, not_allowed_user_ids) — wraps PATCH /connected_accounts/{id}
with the same semantics as the TS sibling. PATCH semantics: omit a
param to leave unchanged; pass [] to clear an allow/deny list. Raises
ValidationError if all three are None.
- composio.tool_router_session.authorize() options gain `account_type`
and `acl_config_for_shared` — the /tool_router/session/{id}/link
endpoint accepts the same fields.
- New typed errors in composio.exceptions:
* ComposioAclOnlyForSharedError (400) — wired at link() / update_acl()
/ authorize() catch sites via the same
`acl_config_for_shared is only valid on SHARED` substring match used
in the TS SDK. Verified against Apollo's createConnectedAccount.ts.
* ComposioSharedAccessDeniedError (403) — exported, not yet wrapped.
Wraps when Tools.execute() error mapping lands in a follow-up.
* ComposioSharedConnectionNotAccessibleError (400) — exported, not
yet wrapped. Wraps when ToolRouterSession.create()/patch() session-
validator error mapping lands.
Plumbing:
- python/composio/client/types.py re-exports `link_create_params` (the
generated client's TypedDicts for link create payloads, including
`ACLConfigForShared`).
Tests: 12 new tests in TestConnectedAccountsAcl class covering link()
ACL forwarding (4), AclOnlyForShared mapping on link() (1), pass-through
of unrelated BadRequestError (1), update_acl() body construction (3),
empty-fields rejection (1), AclOnlyForShared mapping on update_acl() (1),
pass-through of unrelated BadRequestError on update_acl() (1). 49 tests
pass (37 pre-existing + 12 new); full suite 635 pass / 31 skipped.
Verified: nox -s chk clean (ruff + mypy on src + tests).
Version: 0.13.0 → 0.14.0 (minor — additive surface).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The connected_account_patch_params and connected_account_patch_response
types exist in composio-client 1.31.0 but weren't re-exported from the
wrapper module.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Zen Agent <zen@composio.dev>
Deep Gori