feat: allow queuing messages during compression (#24071)#26506
Conversation
Summary of ChangesHello, 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 improves the user experience during chat history compression by enabling background execution. By shifting to an asynchronous model and utilizing derived state, the application now allows users to queue messages while compression is in progress, avoiding UI blocks and resolving issues with conflicting loading indicators. 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 the 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 counterproductive. 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. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces logic to queue user messages while a background chat history compression task is active, preventing concurrent state modifications. Key changes include the addition of an isCompressing state in the AppContainer, updates to the useMessageQueue hook to pause processing during compression, and a refactor of the compressCommand to handle execution asynchronously. Feedback highlights the need to also queue slash commands during compression to maintain total state consistency and suggests refining the management of the pendingItem state in compressCommand to avoid UI glitches during concurrent command executions.
|
Size Change: +458 B (0%) Total Size: 34 MB
ℹ️ View Unchanged
|
cocosheng-g
force-pushed
the
issue-24071-v2
branch
3 times, most recently
from
5d8924b to
aebbca4
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request transitions the chat history compression process into an asynchronous background task and implements a queuing system for user inputs during active compression. Changes include the introduction of an "isCompressing" state in AppContainer and logic in useMessageQueue to defer message processing. Feedback highlights that slash commands are currently being queued alongside regular messages, which unnecessarily blocks immediate system commands like /quit or /help; it is recommended to allow these commands to bypass the compression check to ensure the CLI remains responsive.
gemini-cli
Bot
added
priority/p3
cocosheng-g
force-pushed
the
issue-24071-v2
branch
3 times, most recently
from
74eb2de to
c191344
Compare
|
Size Change: +464 B (0%) Total Size: 34 MB
ℹ️ View Unchanged
|
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request implements message queuing during chat history compression to prevent UI blocking and ensure message order. It introduces an isCompressing state in AppContainer and updates the useMessageQueue hook to defer query submission until compression is complete. The compressCommand was also updated to run its logic in a non-blocking background task. The reviewer suggests restoring the async keyword to the compressCommand action to maintain type compatibility with the SlashCommand interface.
cocosheng-g
force-pushed
the
issue-24071-v2
branch
from
c191344 to
a36d1d5
Compare
2 participants
Summary
This PR allows users to queue messages while chat history compression is running. It introduces a highly robust, derived-state design that requires minimal changes to the existing architecture, completely avoiding state conflicts and duplicate loading indicators.
Details
To enable seamless background maintenance, the
/compresscommand has been updated to execute asynchronously. This immediately releases the globalisProcessingUI lock, allowing the user to interact with the input prompt without being blocked.Crucially, rather than passing a fragile new boolean state throughout the application, the
isCompressingstate is now purely derived from the existingpendingHistoryItemslist (specifically looking for an activeMessageType.COMPRESSIONitem).slashCommandProcessor,useGeminiStream, and the coreStreamingStateenum retain their exact original behaviors. No new Context values or global states were added.isCompressingis derived from the history item (which renders its own inline spinner), the globalLoadingIndicator("Thinking...") naturally stays hidden since thestreamingStateremainsIdle. This completely solves the duplicate loading indicator bug.useMessageQueue. BecauseisAgentRunningcorrectly evaluates to false (asstreamingStateisIdleand no tools are executing), there is zero risk of triggering the model steering hint logic.Key Changes:
compressCommand.ts: Wrapped the compressiontry/catchin a non-awaited asynchronous IIFE.AppContainer.tsx: DerivedisCompressingfrompendingHistoryItems. UpdatedhandleFinalSubmitto route input into the queue when this state is active.useMessageQueue.ts: Updated to accept ashouldQueueboolean, generalizing the hook to queue during any active background system task (like compression).AppContainer.test.tsx: Added a comprehensive unit test verifying that messages are queued during compression without triggering steering hints.Related Issues
Closes #24071
How to Validate
/compress.Pre-Merge Checklist