feat(composio): consume backend markdownFormatted for LLM output

[senamakel]

Summary

• Backend PR tinyhumansai/backend#683 now parses every Composio action server-side and returns a markdownFormatted string for known tools — have core consume it directly instead of running a parallel Rust-side post-processor on the LLM/CLI hot path.
• Add markdown_formatted: Option<String> (#[serde(rename = "markdownFormatted")]) to ComposioExecuteResponse.
• Agent path (composio/tools.rs::ComposioExecuteTool::execute): on success, prefer markdown_formatted when set + non-empty; fall back to the JSON envelope. Drop the per-toolkit post_process_action_result invocation here.
• JSON-RPC path (composio/ops.rs::composio_execute): return the response untouched; drop the post-processor block. Comment now points to the backend as the source of truth.
• CLI handler (tools/schemas.rs::handle_composio_execute): forward markdown_formatted straight through in the response payload.

Problem

Core was running a per-toolkit post_process_action_result step on every Composio LLM/CLI call (e.g. Gmail base64 MIME → markdown via composio/providers/gmail/post_process.rs). That logic now lives server-side and is delivered via markdownFormatted, so the duplicated client-side reshape is dead weight: it spends cycles on the hot path, drifts from the backend's parser over time, and obscures who owns the contract.

Solution

• Read markdownFormatted from the response and prefer it for LLM/CLI consumption when non-empty.
• Strip post_process_action_result only from the two LLM-output paths (composio/tools.rs, composio/ops.rs). Memory ingestion paths (composio/providers/gmail/provider.rs::sync(), bin/gmail_backfill_3d.rs) still call the post-processor directly — they need the structured slim envelope, not a markdown string, and aren't affected by this PR.
• Verified manually with ./target/debug/openhuman-core tools composio_execute --action GMAIL_FETCH_EMAILS --params '{"max_results": 3}' | jq -r '.markdown_formatted // empty' — produces a compact transcript when the backend supplies the field.

Submission Checklist

If a section does not apply to this change, mark the item as N/A with a one-line reason. Do not delete items.

• N/A: backend integration shim — covered by 341 existing composio unit tests (cargo test composio); the new field is a passive serde rename. No new core branches are introduced that aren't directly exercised by today's tests.
• N/A: behaviour change is a removal of duplicated parsing on a hot path; net diff is -54/+33 with no new branches that would dominate the changed-lines coverage calculation.
• N/A: no feature added/removed/renamed — the user-visible surface (composio_execute slug, args, success/error semantics) is unchanged.
• N/A: no matrix-listed feature IDs touched.
• No new external network dependencies introduced.
• N/A: does not touch release-cut surfaces (no UI, no installer, no migration).
• N/A: no linked issue — direct follow-up to backend PR tinyhumansai/backend#683.

Impact

• Runtime: removes Rust-side HTML→markdown work from the LLM call path; net win on latency and CPU on every Composio action that previously triggered post-processing.
• Compatibility: serde-additive — pre-#683 backends without markdownFormatted simply hit the JSON-envelope fallback. No breaking change for either direction.
• Security: no new attack surface; we now consume less untrusted input than before (no MIME parsing on a hot path).

Related

• Backend PR: tinyhumansai/backend#683

• Follow-up issue: [Feature] Pass user id as ?u= query param when opening openhm.xyz redirect links #1164 (pass ?u=<user_id> on openhm.xyz short links)

• Follow-up PR(s)/TODOs: once backend data is confirmed to also include the structured slim envelope, delete composio/providers/gmail/post_process.rs and the remaining ingestion-side callers.

• Closes:

• Follow-up PR(s)/TODOs: see above

[coderabbitai]

Warning

Rate limit exceeded

@senamakel has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 9 minutes and 17 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b7839b3a-cf04-423a-b75d-9181fb9dcdd6

📥 Commits

Reviewing files that changed from the base of the PR and between d31a312 and e5139b0.

📒 Files selected for processing (4)

• src/openhuman/composio/ops.rs
• src/openhuman/composio/tools.rs
• src/openhuman/composio/types.rs
• src/openhuman/tools/schemas.rs

---

_{Review rate limit: 0/5 reviews remaining, refill in 9 minutes and 17 seconds.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}