Fix race condition by awaiting scheduleToolCalls

[chrstnb]

Summary

We've been seeing a lot of errors like this: #16415

This was caused by sending requests that looked something like this:

Role: Model
Function Call: write_file (file_1.py)
Function Call: replace (file_2.py)
Function Call: replace (file_3.py)
Function Call: run_shell_command (rm file_4.py)
Function Call: write_file (README.md)

Role: User
Function Response: write_file (Success: file_1.py)

Role: User
Function Response: write_file (Success: file_1.py)
Function Response: replace (Success: file_2.py)
Function Response: replace (Success: file_3.py)
Function Response: run_shell_command (Success: rm file_4.py)
Function Response: write_file (Success: README.md)

Note that we are providing the function response to the first write_file call twice.

My theory is that this is happening a) only in yolo mode and b) when a user queues a message via the input prompt while the tool calls are still running.

This meant the main chat loop thought it was "done" (Idle) for a split second while the tool was still getting ready to run. Because the system briefly reported "Idle", the queued message was immediately grabbed and sent. This started a new conversation turn while the old tool turn was still happening, causing the model to get confused and the history to be fragmented.

I changed the code to await the tool scheduling. Now, the system explicitly says "I am busy (Responding)" until the tool has been fully scheduled.

Details

Related Issues

How to Validate

In order to validate, prompt the CLI with this prompt:

There's a race condition with you (gemini cli) where sometimes we send tool call responses prematurely or in the wrong order.

Role: Model
Function Call: write_file (file_1.py)
Function Call: replace (file_2.py)
Function Call: replace (file_3.py)
Function Call: run_shell_command (rm file_4.py)
Function Call: write_file (README.md)

Role: User
Function Response: write_file (Success: file_1.py)

Role: User
Function Response: write_file (Success: file_1.py)
Function Response: replace (Success: file_2.py)
Function Response: replace (Success: file_3.py)
Function Response: run_shell_command (Success: rm file_4.py)
Function Response: write_file (Success: README.md)


The above is an example of an invalid request we sent to the API on the backend (it does not map to any formatting you are aware of, but has been made human-readable). Can you try to reproduce this by making tool calls and editing / writing/replacing files etc? Try a bunch of different things until we get an error.

Then, while it's running tool calls, enqueue a message.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux
    • npm run
    • npx
    • Docker

[gemini-code-assist]

Summary of Changes

Hello @chrstnb, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses and resolves a race condition related to the scheduling of tool calls. By transitioning the scheduleToolCalls function to an asynchronous operation and ensuring it is properly awaited, the changes guarantee that tool scheduling completes reliably before dependent processes continue. This enhances the stability and predictability of the tool execution flow within the application.

Highlights

• Race Condition Fix: Introduced await to calls of scheduleToolCalls within useGeminiStream.ts to ensure that tool scheduling operations complete before subsequent stream processing, thereby resolving a potential race condition.
• Asynchronous Function Signature Update: Modified the ScheduleFn type in useReactToolScheduler.ts to correctly reflect that the schedule function is now asynchronous and returns a Promise<void>, allowing it to be awaited by callers.
• Test Suite Adaptation: Updated multiple test cases in useToolScheduler.test.ts to properly handle the asynchronous nature of the schedule function by wrapping calls in await act(async () => { await ... }), ensuring reliable testing of the new asynchronous behavior.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-cli]

Hi @chrstnb, thank you so much for your contribution to Gemini CLI! We really appreciate the time and effort you've put into this.

We're making some updates to our contribution process to improve how we track and review changes. Please take a moment to review our recent discussion post: Improving Our Contribution Process & Introducing New Guidelines.

Key Update: Starting January 26, 2026, the Gemini CLI project will require all pull requests to be associated with an existing issue. Any pull requests not linked to an issue by that date will be automatically closed.

Thank you for your understanding and for being a part of our community!

[github-actions]

Size Change: +12 B (0%)

Total Size: 23.1 MB

ℹ️ View Unchanged

Filename	Size	Change
./bundle/gemini.js	23.1 MB	+12 B (0%)
./bundle/sandbox-macos-permissive-closed.sb	1.03 kB	0 B
./bundle/sandbox-macos-permissive-open.sb	890 B	0 B
./bundle/sandbox-macos-permissive-proxied.sb	1.31 kB	0 B
./bundle/sandbox-macos-restrictive-closed.sb	3.29 kB	0 B
./bundle/sandbox-macos-restrictive-open.sb	3.36 kB	0 B
./bundle/sandbox-macos-restrictive-proxied.sb	3.56 kB	0 B

_{compressed-size-action}

[gemini-code-assist]

Code Review

This pull request correctly addresses a race condition by making scheduleToolCalls asynchronous and awaiting its promise. The changes are consistently applied across the affected files, including type definitions and test updates. My review includes one high-severity comment regarding a potential unhandled promise rejection that could occur if scheduleToolCalls rejects, which has been kept as it aligns with good error handling practices.

[chrstnb]

/patch

[github-actions]

✅ Patch workflow(s) dispatched successfully!

📋 Details:

• Channels: stable,preview
• Commit: cfdc4cfca8162e99cdfd169b8765031847ef5296
• Workflows Created: 2

🔗 Track Progress:

• View patch workflows
• This workflow run

[github-actions]

🚀 Patch PR Created!

📋 Patch Details:

• Environment: prod
• Channel: stable → will publish to npm tag latest
• Commit: cfdc4cfca8162e99cdfd169b8765031847ef5296
• Hotfix Branch: hotfix/v0.24.0/0.24.1/stable/cherry-pick-cfdc4cf/pr-16759
• Hotfix PR: #16865

📝 Next Steps:

1. Review and approve the hotfix PR: #16865
2. Once merged, the patch release will automatically trigger
3. You'll receive updates here when the release completes

🔗 Track Progress:

• View hotfix PR #16865

[github-actions]

🚀 Patch PR Created!

📋 Patch Details:

• Environment: prod
• Channel: preview → will publish to npm tag preview
• Commit: cfdc4cfca8162e99cdfd169b8765031847ef5296
• Hotfix Branch: hotfix/v0.25.0-preview.0/0.25.0-preview.1/preview/cherry-pick-cfdc4cf/pr-16759
• Hotfix PR: #16866

📝 Next Steps:

1. Review and approve the hotfix PR: #16866
2. Once merged, the patch release will automatically trigger
3. You'll receive updates here when the release completes

🔗 Track Progress:

• View hotfix PR #16866

[github-actions]

🚀 Patch Release Started!

📋 Release Details:

• Environment: prod
• Channel: stable → publishing to npm tag latest
• Version: v0.24.0
• Hotfix PR: Merged ✅
• Release Branch: release/v0.24.0-pr-16759

⏳ Status: The patch release is now running. You'll receive another update when it completes.

🔗 Track Progress:

• View release workflow

[github-actions]

🚀 Patch Release Started!

📋 Release Details:

• Environment: prod
• Channel: preview → publishing to npm tag preview
• Version: v0.25.0-preview.0
• Hotfix PR: Merged ✅
• Release Branch: release/v0.25.0-preview.0-pr-16759

⏳ Status: The patch release is now running. You'll receive another update when it completes.

🔗 Track Progress:

• View release workflow

[github-actions]

❌ Patch Release Failed!

📋 Details:

• Version: 0.25.0-preview.1
• Channel: preview
• Error: The patch release workflow encountered an error

🔍 Next Steps:

1. Check the workflow logs for detailed error information
2. The maintainers have been notified via automatic issue creation
3. You may need to retry the patch once the issue is resolved

🔗 Troubleshooting:

• View workflow run
• View workflow logs

[github-actions]

❌ Patch Release Failed!

📋 Details:

• Version: 0.24.1
• Channel: stable
• Error: The patch release workflow encountered an error

🔍 Next Steps:

1. Check the workflow logs for detailed error information
2. The maintainers have been notified via automatic issue creation
3. You may need to retry the patch once the issue is resolved

🔗 Troubleshooting:

• View workflow run
• View workflow logs

[github-actions]

❌ Patch Release Failed!

📋 Details:

• Version: 0.24.1
• Channel: stable
• Error: The patch release workflow encountered an error

🔍 Next Steps:

1. Check the workflow logs for detailed error information
2. The maintainers have been notified via automatic issue creation
3. You may need to retry the patch once the issue is resolved

🔗 Troubleshooting:

• View workflow run
• View workflow logs

[github-actions]

❌ Patch Release Failed!

📋 Details:

• Version: 0.25.0-preview.1
• Channel: preview
• Error: The patch release workflow encountered an error

🔍 Next Steps:

1. Check the workflow logs for detailed error information
2. The maintainers have been notified via automatic issue creation
3. You may need to retry the patch once the issue is resolved

🔗 Troubleshooting:

• View workflow run
• View workflow logs

[github-actions]

✅ Patch Release Complete!

📦 Release Details:

• Version: 0.25.0-preview.1
• NPM Tag: preview
• Channel: preview
• Dry Run: false

🎉 Status: Your patch has been successfully released and published to npm!

📝 What's Available:

• GitHub Release: View release v0.25.0-preview.1
• NPM Package: npm install @google/gemini-cli@preview

🔗 Links:

• GitHub Release
• Workflow Run

[jw409]

Thanks for catching this race condition with scheduleToolCalls!

We discovered a related race condition in the same area and opened #16146 to fix it. Our fix awaits submitQuery before calling markToolsAsSubmitted, preventing user prompts from racing ahead of tool responses.

Your fix (awaiting scheduleToolCalls) and ours address different timing windows in the tool lifecycle - both are necessary to fully close the race condition gaps.

Let's coordinate on merge order to avoid conflicts. Happy to rebase on top of yours once it lands, or we can combine both fixes into one PR if you prefer.