fix(core): send shell output to model on cancel

[devr0306]

Summary

The shell output was getting dropped when users canceled before the shell finished running. There will be a follow-up PR to show the cancelled output in the UI.

Details

Passed the partial shell output from shell.ts all the way up to state-manager.ts.

Related Issues

Fixes #19512

How to Validate

1. Ask Gemini CLI "can you run npm test -w @google/gemini-cli"
2. Cancel before it finishes running
3. Ask "Can you give me the shell output before I canceled"
4. It should show a summary of the output. You can also ask for the entire output

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, 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 an issue where shell command output was lost upon cancellation. It introduces changes across the tool execution and state management layers to ensure that any partial output generated by a shell command before it is cancelled is captured and made available to the model. This significantly improves the user experience by providing valuable context even when operations are interrupted.

Highlights

• Enhanced Cancellation Data: Modified the core tool scheduling and state management to store detailed ToolCallResponseInfo objects, including partial output, when a tool execution is cancelled, instead of just a generic string message.
• Partial Output Retention: Updated the ToolExecutor to capture and include any available llmContent (partial output) from a tool's execution in the ToolCallResponseInfo when the operation is aborted.
• Improved Shell Tool Feedback: The shell.ts tool now formats the cancellation message to explicitly include any partial output that was generated before the command was cancelled, providing better context to the user.
• Type Safety and Validation: Introduced a isToolCallResponseInfo type guard in CoreToolScheduler and SchedulerStateManager to ensure correct data handling for tool call responses.
• Comprehensive Testing: Added a new test case to tool-executor.test.ts specifically to verify that cancelled tool results correctly contain partial output.

Changelog

• packages/core/src/core/coreToolScheduler.ts
  • Ensured that auxiliaryData is validated as ToolCallResponseInfo for Success, Error, and Cancelled tool call statuses.
  • Added a private isToolCallResponseInfo type guard method.
• packages/core/src/scheduler/scheduler.test.ts
  • Updated the expected argument for mockStateManager.updateStatus for cancelled calls to be a ToolCallResponseInfo object.
• packages/core/src/scheduler/scheduler.ts
  • Modified the updateStatus call for cancelled operations to pass the result.response object, which now contains detailed cancellation information.
• packages/core/src/scheduler/state-manager.ts
  • Updated the updateStatus method signature to accept string | ToolCallResponseInfo for CoreToolCallStatus.Cancelled.
  • Adjusted the toCancelled method to handle both string reasons and ToolCallResponseInfo objects, constructing the CancelledToolCall accordingly.
  • Enhanced validation for auxiliaryData during Cancelled transition to check for ToolCallResponseInfo.
• packages/core/src/scheduler/tool-executor.test.ts
  • Added a new test case to confirm that a cancelled tool execution returns a CancelledToolCall containing partial output and a formatted resultDisplay.
• packages/core/src/scheduler/tool-executor.ts
  • Modified createCancelledResult to accept an optional toolResult parameter.
  • Included llmContent from toolResult in the responseBody of the ToolCallResponseInfo for cancelled calls.
  • Updated resultDisplay to use toolResult.returnDisplay if available.
  • Adjusted contentLength calculation to reflect the new responseBody.
• packages/core/src/tools/shell.ts
  • Refactored the logic for generating returnDisplayMessage for aborted shell commands to include result.output if present, providing "Output before cancellation" context.

Activity

• The pull request was created to fix issue When a shell script is cancelled the model doesn't see its output #19512, addressing the loss of shell output on cancellation.
• The author has indicated that tests were added/updated and validated on MacOS using npm run.

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-code-assist]

Code Review

This pull request effectively addresses an issue where shell output was lost upon cancellation, ensuring partial output from the shell tool is propagated through the tool-executor and scheduler layers to the model for context. While the implementation includes robust type-safe handling of cancellation data, comprehensive new tests, and improved logic in shell.ts, a critical security vulnerability was identified. The ToolExecutor's newly added cancelled result path lacks the output truncation logic present in the success path. This omission could lead to memory exhaustion and Denial of Service if a cancelled command produces a large volume of output. It is highly recommended to apply consistent output truncation across all terminal tool states to address this security concern.

[github-actions]

Size Change: +2.57 kB (+0.01%)

Total Size: 25.9 MB

Filename	Size	Change
./bundle/gemini.js	25.4 MB	+2.57 kB (+0.01%)

ℹ️ View Unchanged

Filename	Size
./bundle/node_modules/@google/gemini-cli-devtools/dist/client/main.js	221 kB
./bundle/node_modules/@google/gemini-cli-devtools/dist/src/_client-assets.js	227 kB
./bundle/node_modules/@google/gemini-cli-devtools/dist/src/index.js	11.5 kB
./bundle/node_modules/@google/gemini-cli-devtools/dist/src/types.js	132 B
./bundle/sandbox-macos-permissive-open.sb	890 B
./bundle/sandbox-macos-permissive-proxied.sb	1.31 kB
./bundle/sandbox-macos-restrictive-open.sb	3.36 kB
./bundle/sandbox-macos-restrictive-proxied.sb	3.56 kB
./bundle/sandbox-macos-strict-open.sb	4.82 kB
./bundle/sandbox-macos-strict-proxied.sb	5.02 kB

_{compressed-size-action}

[jacob314]

Thanks for this PR! The implementation for sending partial shell output back to the model upon cancellation is solid. Extracting the output truncation logic so it applies uniformly is a great approach.

I've reviewed the code against our project guidelines and have a few suggestions to improve maintainability and consistency:

Improvements

1. Code Duplication of Type Guard
The type guard isToolCallResponseInfo(data: unknown): data is ToolCallResponseInfo is duplicated in both packages/core/src/core/coreToolScheduler.ts and packages/core/src/scheduler/state-manager.ts.
Suggestion: Consider moving this type guard to packages/core/src/scheduler/types.ts where ToolCallResponseInfo is defined, or another shared utility file. This will reduce boilerplate and centralize the type-checking logic.

2. Handling of resultDisplay in tool-executor.ts
In packages/core/src/scheduler/tool-executor.ts (inside createCancelledResult), the resultDisplay is strictly checked for a string:

resultDisplay:
  typeof toolResult?.returnDisplay === 'string'
    ? toolResult.returnDisplay
    : undefined,

While this works perfectly for the shell tool (which produces a string upon cancellation), if another tool that returns a complex ToolResultDisplay object is somehow cancelled during execution, its visual display would be lost.
Suggestion: Consider whether we should just use toolResult?.returnDisplay directly, similar to how it is handled in createSuccessResult.

Nitpicks / Observations

3. Type Assertions in Tests
I noticed a few type assertions in packages/core/src/scheduler/tool-executor.test.ts like invocation as unknown as AnyToolInvocation and ?.response as Record<string, unknown>. While our project rules advise strictly avoiding any, the use of unknown and type narrowing here aligns with the testing guidelines for mocking nested objects. Just pointing it out as an observation!

Overall, great work on fixing this issue!

[jacob314]