HITL: Boolean confirmation

[r4inee]

Appends function call from the "confirmed" function invocation to the subsequent LLM request.

Non-gemini models will fail if a function response is not preceeding a function call.

Invalid parameter: messages with role 'tool' must be a response to a preceeding message with 'tool_calls'.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Summary of Changes

Hello @r4inee, 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 introduces a crucial human-in-the-loop (HITL) boolean confirmation feature, allowing for explicit user approval or denial of tool executions within the LLM agent system. The core change ensures that after a tool invocation is confirmed or declined, the outcome (the original function call and its response) is appended to the subsequent LLM request. This provides the LLM with complete context regarding the execution status of previously suggested tools. The implementation involves updating the LlmAgent for asynchronous tool handling, enhancing function call processing to respect confirmation statuses, and integrating a dedicated request processor into the LLM flow.

Highlights

• Asynchronous Tool Retrieval: The LlmAgent's tools() method now returns a Single<List<BaseTool>>, enabling asynchronous retrieval of tools rather than a blocking call.
• Tool Confirmation Handling: The Functions utility now explicitly checks for ToolConfirmation status, allowing for user-declined tool executions to be handled gracefully by returning an error event.
• Enhanced Request Processing for Confirmations: The RequestConfirmationLlmRequestProcessor has been significantly refactored to accurately identify, process, and append both the original function call and its response (after confirmation) to the subsequent LLM request, providing crucial context.
• Integration into LLM Flow: The new confirmation processing logic is now integrated into the SingleFlow's request processing chain, ensuring it's applied to relevant LLM interactions.
• Runner Adaptations: The Runner class has been updated to correctly initialize activeStreamingTools based on the asynchronous LlmAgent.tools() method, and related logic has been refactored into helper methods.

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 introduces a human-in-the-loop (HITL) boolean confirmation flow for tool/function calls. The changes are well-implemented, particularly the core logic in RequestConfirmationLlmRequestProcessor which now correctly handles user confirmations and denials, and feeds the outcome back to the LLM. The refactoring to use non-blocking reactive patterns in LlmAgent and Runner is a significant improvement to asynchronicity and performance. The accompanying tests are thorough, covering new functionality and edge cases like user denials and avoiding duplicate tool executions. I have one suggestion to improve the clarity and efficiency of a loop.

[gemini-code-assist]

The loop for finding the original function call request starts its search from near the end of the event list (events.size() - 2). While this is functionally correct because you iterate backwards and return upon finding the first match, it's slightly inefficient and less clear. It unnecessarily scans events that occurred after the confirmation event, which cannot contain the relevant request.

A more direct and efficient approach would be to start the search from the event immediately preceding the confirmationEventIndex that you've already identified. This makes the code's intent clearer and avoids iterating over irrelevant events.

Suggested change

	for (int i = events.size() - 2; i >= 0; i--) {
	for (int i = confirmationEventIndex - 1; i >= 0; i--) {