@kaavee315draftchecks…fix/meta-tool-error-result → master3 files · +234 −32updated 6d agoFAILED_EXECUTION_FOR_COMPOSIO_TOOL_RESPONSE and INVALID_REQUEST_FOR_COMPOSIO_TOOL_RESPONSE in apps/apollo/src/lib/tool_execution/execute_tool_utils.ts previously returned Ok({successful:false, ...}), causing the route handler at apps/apollo/src/pages/api/v3/tools/execute/[tool_slug]/index.ts:439 to send HTTP 200 on all meta-tool failures (the !executionResult.ok guard was never triggered). Callers checking HTTP status codes therefore treated these failures as successes.
The fix changes both helpers to return Err(...): INVALID_REQUEST_FOR_COMPOSIO_TOOL_RESPONSE now wraps HTTPErrors.BadRequest (HTTP 400) and FAILED_EXECUTION_FOR_COMPOSIO_TOOL_RESPONSE passes the existing typed error object through directly. executeComposioToolLocally's return type is updated from Result<ComposioToolResponse, never> to the real error union, and its single caller in executeTool now guards on metaResult.err and returns Err(metaResult.val), which the existing errorToHTTPException path in the route handler converts to the correct HTTP status code.
Helper functions in execute_tool_utils.ts (executeRemoteWorkbench, executeRemoteBash, executeMultiExecuteTool, executeManageConnections, executeWaitForConnection) also had their return types updated from Promise<Ok<...>> to Promise<Result<..., Error_400 | ...>> to align with the new builder signatures.
executeComposioToolLocally: exactly one caller exists (in executeTool), which now correctly guards on metaResult.err[tool_slug]/index.ts:439 already calls errorToHTTPException on !executionResult.ok; propagated Err will now reach it for meta-tool failuresexecuteTool return type union to ensure Error_400 | Error_500 (the cast used) is covered in the return union🤖 Generated with Claude Code