-
Notifications
You must be signed in to change notification settings - Fork 10.7k
fix(cli): loop retry race condition with synchronous blocking #17062
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Adds isRespondingRef to provide synchronous blocking of concurrent queries. React state updates are batched, so checking streamingState alone wasn't sufficient - the loop retry's submitQuery could race with user prompts because the state update wasn't visible immediately. Changes: - Add isRespondingRef mirror of isResponding state for synchronous checks - Update guard at line 949 to check isRespondingRef.current - Set isRespondingRef.current = true/false alongside setIsResponding calls - Make loop detection onComplete callback async and await submitQuery - Add regression test that verifies user prompts are blocked during retry The test demonstrates the race condition by: 1. Triggering loop detection 2. Making the retry slow (controlled promise) 3. User selecting "disable" (triggers retry) 4. Attempting to send user prompt while retry is in progress 5. Verifying retry finishes before user prompt starts References: google-gemini#16144, google-gemini#16220
Summary of ChangesHello @jw409, I'm Gemini Code Assist1! 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 resolves a critical race condition in the CLI's query submission logic. Previously, when a user responded to a loop detection prompt by disabling it, the subsequent retry query could race with new user input due to the asynchronous nature of React state updates. The fix introduces a synchronous reference to the Highlights
Using Gemini Code AssistThe 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
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 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
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request addresses a race condition in the loop detection retry mechanism. The fix introduces a useRef (isRespondingRef) to synchronously track the responding state, preventing new user queries from starting while a retry is in progress. The onComplete handler for loop detection is also made async to properly await the retry query. The changes are well-implemented and are accompanied by a thorough regression test that validates the fix. The code looks good, and I have no further comments.
|
Fixes #17071 |
|
✅ Preflight verified locally: 4091 tests pass, 1 known flaky test (MCP OAuth timeout - tracked separately). |
Fixes #17071