Skip to content

fix(api): return a clear not-configured status for tool and trigger discovery when Composio is unset - #5812

Open
mmabrouk wants to merge 1 commit into
release/v0.110.0from
fix/composio-not-configured-error-5407
Open

fix(api): return a clear not-configured status for tool and trigger discovery when Composio is unset#5812
mmabrouk wants to merge 1 commit into
release/v0.110.0from
fix/composio-not-configured-error-5407

Conversation

@mmabrouk

@mmabrouk mmabrouk commented Aug 7, 2026

Copy link
Copy Markdown
Member

Summary

On a self-hosted deployment without COMPOSIO_API_KEY set, POST /tools/discover and POST /triggers/discover (and any other adapter lookup for the composio provider) returned a bare 404"Provider not found: composio". That reads as "endpoint missing," so a self-hoster can't tell a real bug from a missing setup step.

Before: 404 Not Found{"detail": "Provider not found: composio"}

After: 503 Service Unavailable{"detail": "composio is not configured on this deployment. Set COMPOSIO_API_KEY to enable it."}

A genuinely unknown provider_key (a typo, or any value other than composio) still returns 404 — that distinction matters because provider is a free-form string field on the request body, not a validated enum.

Root cause

ToolsGatewayRegistry.get() / TriggersGatewayRegistry.get() raise a single ProviderNotFoundError for any missing adapter, whether the key is genuinely unknown or just unconfigured (composio's adapter is only registered when env.composio.enabled is true). The router's handle_adapter_exceptions mapped that one exception straight to 404.

Fix

  • Added ProviderNotConfiguredError to both oss.src.core.tools.exceptions and oss.src.core.triggers.exceptions — raised when a provider is recognized by the deployment but its adapter wasn't built due to missing config.
  • Both ToolsGatewayRegistry and TriggersGatewayRegistry now accept an unconfigured: Dict[provider_key, env_var] map. get() raises ProviderNotConfiguredError for keys in that map instead of the generic ProviderNotFoundError.
  • api/entrypoints/routers.py wires unconfigured={"composio": "COMPOSIO_API_KEY"} when env.composio.enabled is false.
  • handle_adapter_exceptions in both the tools and triggers FastAPI routers now maps ProviderNotConfiguredError503 with the env var named in the detail message, before falling back to 404 for ProviderNotFoundError.

Since registry.get() is the single choke point every tools/triggers adapter call goes through (discovery, catalog browse, resolve, execute), this fix isn't discovery-only — any call that hits the unconfigured composio provider now gets the same clear 503 instead of a bare 404.

Testing

Added targeted unit tests for both domains:

  • api/oss/tests/pytest/unit/tools/test_discovery.py — router-level test asserting POST /tools/discover maps ProviderNotConfiguredError to 503 with COMPOSIO_API_KEY in the detail, plus registry-level tests distinguishing "known but unconfigured" from "unknown provider."
  • api/oss/tests/pytest/unit/triggers/test_triggers_discovery.py — same coverage for POST /triggers/discover.

Ran the full tools + triggers unit suites locally: 238 passed. ruff format --check and ruff check clean on all touched files.

Fixes #5407

…iscovery when Composio is unset

Before: on a self-hosted deployment without COMPOSIO_API_KEY set, POST
/tools/discover and POST /triggers/discover returned a bare 404 ("Provider
not found: composio"). That reads as "endpoint missing", so a self-hoster
can't tell a bug from a missing setup step.

After: the tools/triggers gateway registries now distinguish a provider this
deployment recognizes but hasn't configured (composio without
COMPOSIO_API_KEY) from a provider that genuinely doesn't exist. The former
raises a new ProviderNotConfiguredError, mapped by handle_adapter_exceptions
to 503 with a message naming the missing env var
("composio is not configured on this deployment. Set COMPOSIO_API_KEY to
enable it."). A truly unknown provider_key still 404s. Since registry.get()
is the single choke point for tools/triggers adapter lookups, the fix also
covers resolve/execute paths that hit an unconfigured provider, not just
discovery.

Fixes #5407
@dosubot dosubot Bot added the size:L This PR changes 100-499 lines, ignoring generated files. label Aug 7, 2026
@vercel

vercel Bot commented Aug 7, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
agenta-documentation Ready Ready Preview Aug 7, 2026 7:10pm

Request Review

@coderabbitai

coderabbitai Bot commented Aug 7, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6b7a9b65-9b0a-4d31-b6cb-56f0994f6c5e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions

github-actions Bot commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Railway Preview Environment

Preview URL https://gateway-pr-5812.up.railway.app/w
Project agenta-oss-clone-spike
Image tag pr-5812-84f9696
Status Deployed
Railway logs Open logs
Workflow logs View workflow run
Updated at 2026-08-07T19:18:35.409Z

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backend size:L This PR changes 100-499 lines, ignoring generated files. tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant