fix: handle partial tool call execution failures and return successful results

[impoiler]

Summary

When executing multiple tool calls in parallel, if some succeed and others fail, the successful results were previously discarded entirely. This PR improves partial failure handling so that successful tool call results are preserved and surfaced back to the UI, allowing users to manually fill in only the failed ones.

Changes

• handleExecuteAllToolCalls now uses Promise.allSettled instead of Promise.all, so individual failures no longer abort the entire batch.
• On partial failure, successful results are returned to the caller instead of being immediately submitted, allowing the UI to pre-populate those responses while leaving failed ones editable.
• The error toast now reports how many of the total tool calls failed and hints that successful results were kept when it's a partial failure.
• onExecuteAllToolCalls return type updated from Promise<void> to Promise<{ toolCallId: string; content: string }[] | undefined> to carry partial results back to ToolCallMessageView.
• ToolCallMessageView now handles the returned partial results by updating its local responses and resolvedIds state, so successfully executed tools appear filled in immediately.
• Replaced crypto.randomUUID() with uuidv4() from the uuid package for consistency.

Type of change

• Bug fix
• Feature
• Refactor
• Documentation
• Chore/CI

Affected areas

• Core (Go)
• Transports (HTTP)
• Providers/Integrations
• Plugins
• UI (React)
• Docs

How to test

1. Configure a prompt with multiple tool calls that can be executed directly.
2. Intentionally cause one tool call to fail (e.g., misconfigure one tool's endpoint or parameters).
3. Click "Execute All" on the tool call message.
4. Verify that the successfully executed tools show their results pre-filled in the UI.
5. Verify that the failed tool call(s) remain editable and a toast appears indicating how many failed.
6. Verify that when all tool calls succeed, behavior is unchanged — results are submitted automatically.

cd ui
pnpm i || npm i
pnpm build || npm run build

Breaking changes

• Yes
• No

Related issues

Security considerations

None.

Checklist

• I read docs/contributing/README.md and followed the guidelines
• I added/updated tests where appropriate
• I updated documentation where needed
• I verified builds succeed (Go and UI)
• I verified the CI pipeline passes locally if applicable

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (2)

• ui/components/prompts/components/messagesView/toolCallView.tsx is excluded by none and included by none
• ui/components/prompts/context.tsx is excluded by none and included by none

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 50de49b5-0125-4226-8014-75a478d58eca

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 05-28-fix_remove_crypto.uuid_to_prevent_error_on_http_contexts

---

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

[impoiler]

• fix: handle partial tool call execution failures and return successful results #3849 👈 (View in Graphite)
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Confidence Score: 5/5

The change is safe to merge — it narrows the blast radius of parallel tool execution failures without altering the all-success path's observable behavior.

The logic is straightforward: Promise.allSettled guarantees no individual rejection aborts the batch, the all-success fast path is unchanged, and partial results flow cleanly through the updated return type into local component state. The two crypto.randomUUID replacements are mechanical. No data-testid attributes were removed, no cross-module contracts were broken, and error handling that was previously missing on the submit step is now wrapped in its own try/catch.

No files require special attention.

Important Files Changed

Filename	Overview
ui/components/prompts/context.tsx	handleExecuteAllToolCalls switched from Promise.all to Promise.allSettled; partial successes are returned to the caller; failures are reported via toast with aggregated error messages; crypto.randomUUID() replaced with uuidv4()
ui/components/prompts/components/messagesView/toolCallView.tsx	handleExecuteAll now processes the returned partial result array, pre-populating responses and resolvedIds for successfully executed tools while leaving failed ones editable; return type updated accordingly

_{Reviews (2): Last reviewed commit: "fix: remove crypto.uuid() to prevent err..." | Re-trigger Greptile}

[Pratham-Mishra04]

Merge activity

• May 28, 2:17 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• May 28, 2:18 PM UTC: @Pratham-Mishra04 merged this pull request with Graphite.