feat: add missing tool resolution strategy

[tkroman]

hi, I'm not sure if I had to create an issue first so please let me know if this is ok.

the use-case is recovering from exceptions thrown as a result of hallucinated tool calls. i tried to preserve behavior by using the current throwing behaviour wherever this new argument is passed.

also, some tests fail locally for me, i'll try to figure it out but hopefully ci passes

[gemini-code-assist]

Summary of Changes

Hello @tkroman, 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 enhances the system's robustness by introducing a configurable strategy for handling missing tool calls. Previously, an attempt to call a non-existent tool would immediately result in an exception. With this change, developers can now define custom behaviors, such as logging an error, returning a specific event, or silently ignoring the call, providing greater control and resilience against 'hallucinated' tool calls from language models.

Highlights

• New Missing Tool Resolution Strategy: Introduced a new MissingToolResolutionStrategy interface to define how the system should react when a requested tool (function call) is not found during execution.
• Configurable RunConfig: The RunConfig now includes a missingToolResolutionStrategy property, allowing developers to configure the behavior for missing tools. The default strategy is THROW_EXCEPTION.
• Enhanced Function Call Handling: The Functions class has been updated to utilize the new resolution strategy, replacing direct VerifyException throws with calls to onMissingTool() when a tool is not found. This allows for more flexible error handling, such as returning an error event or ignoring the call.
• New Test Coverage: Added a new test case to demonstrate and verify the functionality of a custom MissingToolResolutionStrategy that responds with a specific event when a tool is missing.

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 valuable feature for handling missing tool calls by using a configurable resolution strategy, making the agent more robust against model hallucinations. The implementation of MissingToolResolutionStrategy is well-designed.

However, I've found a few issues:

• There is a critical bug in Functions.java that introduces an infinite recursion, which is likely the cause of the local test failures you mentioned.
• There are a couple of places where Optional.get() is used without checking for presence, which could lead to a NoSuchElementException.
• The new MissingToolResolutionStrategy interface implementations can be simplified using lambdas for better readability and conciseness.

I've left detailed comments with suggestions to fix these issues. Once they are addressed, this will be a great addition.

By the way, it's perfectly fine to open a pull request directly for a new feature like this. Thank you for your contribution!