Composio direct mode surfaces entity-id mismatch as an opaque HTTP 400 with the response body discarded #5731

Summary

In Composio direct mode, an entity-id mismatch on action execution surfaces as a bare Composio direct request failed with HTTP 400 Bad Request — the response body, which contains Composio's precise error and its suggested fix, is discarded. Users have no way to discover the actual problem.

Problem

What happened vs expected: with a Gmail connection created through Composio's own dashboard, every execute/sync fails 400. The direct client (vendor/tinymemory/core/src/sync/pipelines/composio/client.rs, execute_direct) does let _ = response.bytes().await; before bailing with just the status line. The discarded body was:

{"error":{"message":"Connected account user ID does not match the provided user ID. …","code":1812,
 "slug":"ActionExecute_ConnectedAccountEntityIdMismatch","status":400,
 "suggested_fix":"The connected_account_id you provided belongs to a different entity. …"}}

Root cause of the mismatch itself: [composio] entity_id defaults to "default", but connections created via Composio's dashboard are filed under a generated user id (pg-test-<uuid> in my case). The app sends both user_id: "default" and the connected_account_id → guaranteed 400 for any dashboard-connected account, presented as an opaque failure.

Steps to reproduce:

1. Direct mode with your own Composio API key; leave entity_id = "default".
2. Connect Gmail via Composio's dashboard (Connect New → OAuth), not via the app.
3. Trigger any action/sync → opaque HTTP 400 Bad Request in logs; sync retries forever.
4. Same request replayed with the connection's actual user_id succeeds.

Version/platform: v0.63.14, macOS, direct mode.

Solution (optional)

Two independent improvements:

1. Surface the body — include (redacted) error.message/slug/suggested_fix in the bail message instead of discarding the bytes. Turns a dead end into a self-explanatory fix.
2. Stop guessing the entity — the app already knows the connected_account_id; it can resolve that account's user_id from /connected_accounts (it lists them elsewhere) and use it for execute, or validate/heal entity_id at connect time, instead of requiring the config value to match by luck.

Workaround: set [composio] entity_id to the connection's user_id (visible via GET /api/v3/connected_accounts).

Acceptance criteria

• Repro gone — a dashboard-created connection either works out of the box (entity resolved from the account) or fails with Composio's actual message including the suggested fix.
• Regression safety — a test pins that a non-2xx direct response propagates the body's error message.
• Diff coverage ≥ 80% — the fix PR meets the changed-lines coverage gate (Vitest + cargo-llvm-cov, enforced by .github/workflows/ci-lite.yml).

Related

—