Problem
reshape_list_threads rewrites GMAIL_LIST_THREADS's payload into a usable thread summary — id, subject, sender, date, labels, snippet, message count. Nothing reads it.
Both Composio dispatch paths build the model-facing body the same way: prefer the backend's markdownFormatted, fall back to the JSON envelope only when it is absent or the call failed. post_process_action_result receives only data, so it cannot clear that field. The reshape runs, rewrites data, and the model is handed the backend rendering instead.
For this action the rendering is the whole problem. Captured verbatim from a live verbose response:
**Gmail Threads** — 2 returned
- `19fbd08f6a3e635b`
- `19fbc77215064e91`
_nextPageToken: 16343739521893202356_
_resultSizeEstimate: 201_
Bare ids. The subjects, senders, dates, labels, and snippets are all present in the payload behind that list, and all discarded. Live, a sub-agent searching for a mail that does exist got the ids, had nothing to recognise the thread by, and reported it could not be found.
Expected
A provider can say that its reshape replaces the backend rendering for a given action, and the dispatch paths honour it.
Constraints
The answer must be per action, not per toolkit. Within Gmail it differs: GMAIL_FETCH_EMAILS's reshape reads markdownFormatted for the message body (already URL-shortened and footer-stripped by the backend), so clearing it there would throw the body away rather than reveal it.
Related
Depends on #5259, which owns the post_process_action_result call sites in the two dispatch paths.
Problem
reshape_list_threadsrewritesGMAIL_LIST_THREADS's payload into a usable thread summary — id, subject, sender, date, labels, snippet, message count. Nothing reads it.Both Composio dispatch paths build the model-facing body the same way: prefer the backend's
markdownFormatted, fall back to the JSON envelope only when it is absent or the call failed.post_process_action_resultreceives onlydata, so it cannot clear that field. The reshape runs, rewritesdata, and the model is handed the backend rendering instead.For this action the rendering is the whole problem. Captured verbatim from a live verbose response:
Bare ids. The subjects, senders, dates, labels, and snippets are all present in the payload behind that list, and all discarded. Live, a sub-agent searching for a mail that does exist got the ids, had nothing to recognise the thread by, and reported it could not be found.
Expected
A provider can say that its reshape replaces the backend rendering for a given action, and the dispatch paths honour it.
Constraints
The answer must be per action, not per toolkit. Within Gmail it differs:
GMAIL_FETCH_EMAILS's reshape readsmarkdownFormattedfor the message body (already URL-shortened and footer-stripped by the backend), so clearing it there would throw the body away rather than reveal it.Related
Depends on #5259, which owns the
post_process_action_resultcall sites in the two dispatch paths.