fix(api): align Composio discover and resolve on one toolkit version (#5174) - #5814
fix(api): align Composio discover and resolve on one toolkit version (#5174)#5814mmabrouk wants to merge 1 commit into
Conversation
…5174) Composio spells action slugs differently per toolkit version and its endpoints scope to different versions by default. The tools adapter ran discovery, resolution, and execution against the v3 default, but COMPOSIO_SEARCH_TOOLS returns slugs spelled at the v3.1 toolkit version. A subset of those slugs 404 with Tool_ToolNotFound (code 2401) when get_action/execute resolve them on v3 — so discovery surfaced "tools that don't exist". Empirical findings against the live Composio API (github/slack/gmail/googlesheets/ notion): - v3 default and v3.1 return DIFFERENT action-slug spellings for the same action. - Of the slugs COMPOSIO_SEARCH_TOOLS recommends, 9 real slugs (e.g. GMAIL_GET_DRAFT, GMAIL_UPDATE_DRAFT, GOOGLESHEETS_VALUES_GET/UPDATE, NOTION_UPSERT_ROW_DATABASE) GET-404 as Tool_ToolNotFound on v3 default but resolve 200 on v3.1. - On v3.1 the whole path is self-consistent: 125/125 v3.1-list slugs GET-resolve AND execute-resolve (never Tool_ToolNotFound); /toolkits and COMPOSIO_SEARCH_TOOLS both work on v3.1; every previously-broken search slug resolves on v3.1. - v3.1 is not backward-lenient to v3's long slugs, so list+get+execute must move together — a partial move would reintroduce the mismatch. Fix: pin only the tools adapter (list/search/get/execute — all in ComposioToolsAdapter) to v3.1 via a new ComposioConfig.tools_api_url, derived from api_url so a self-hosted host override is preserved and only the version segment is forced. The connections, triggers, and integration-catalog adapters talk to version-agnostic /toolkits and are left on v3. Updates the catalog.py:212 comment to reflect that slug consistency now comes from the pinned base URL, not from avoiding a version param. Adds unit tests for the URL derivation and an integration test (COMPOSIO_API_KEY-gated) that a search slug resolves and executes under the pinned scope while still 404-ing on v3. Fixes #5174
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Railway Preview Environment
|
Problem
Composio's discovery path and its resolve/execute path used different implicit toolkit-version scopes, so discovery surfaced tools that resolve/execute then 404 — the "tools that don't exist" bug (#5174).
The tools adapter ran everything against the v3 default, but
COMPOSIO_SEARCH_TOOLSreturns action slugs spelled at the v3.1 toolkit version. Composio spells slugs differently per version, so a subset of search-recommended slugs 404 withTool_ToolNotFound(code 2401) whenget_action/executeresolve them on v3.Empirical findings (live Composio API)
Verified against the live key across github/slack/gmail/googlesheets/notion:
Tool_ToolNotFound) on v3GMAIL_GET_DRAFT,GMAIL_UPDATE_DRAFT,GOOGLESHEETS_VALUES_GET/UPDATE,NOTION_UPSERT_ROW_DATABASE200(GET) and execute-resolve (noTool_ToolNotFound)/toolkits+COMPOSIO_SEARCH_TOOLSon v3.1The execute-side
404 ConnectedAccountNotFound(code 1810) is a different 404 and means the slug was found; onlyTool_ToolNotFound(2401) is the bug.Fix
Pin only the tools adapter (
list/search/get_action/execute— all inComposioToolsAdapter) to Composio API v3.1, via a newComposioConfig.tools_api_url. It's derived fromapi_url, so a self-hosted host override is preserved and only the version segment is forced to v3.1;COMPOSIO_TOOLS_API_URLoverrides it explicitly.The connections, triggers, and integration-catalog adapters only talk to version-agnostic
/toolkits, never surface action slugs, and are left on v3 — keeping the change minimal and avoiding untested changes to auth/webhook flows.The
catalog.pylist comment is updated: slug consistency now comes from the pinned base URL, not from avoiding atoolkit_versionsparam — and the warning against adding a per-call version override is kept.Tests
api/oss/tests/pytest/unit/tools/test_composio_version_alignment.py:tools_api_urlderivation — default→v3.1, already-v3.1, trailing slash, self-hosted host preserved, explicit override.@pytest.mark.integration,COMPOSIO_API_KEY-gated): aCOMPOSIO_SEARCH_TOOLSslug GET-resolves and execute-resolves under the pinned scope, and still 404s asTool_ToolNotFoundon v3 (guards that the pin is load-bearing).All 9 pass with the live key; 42 neighboring tools tests still pass.
ruff format+ruff checkclean.Fixes #5174