Summary of Changes

Hello @caglar10ur, 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 new Go plugin designed to enhance the robustness of tool interactions by implementing a retry and reflection mechanism. It allows tools to gracefully handle failures, providing structured guidance for self-correction and preventing infinite loops of failed attempts. The plugin is configurable to suit different error handling strategies and ensures concurrent-safe tracking of tool failures.

Highlights

• New Go Plugin: Introduced a new Go plugin for 'Retry and Reflect' functionality, mirroring the existing Python version.
• Error Handling and Retries: The plugin provides self-healing, concurrent-safe error recovery for tool failures, allowing tools to retry operations and reflect on errors.
• Configurable Retry Logic: Configurable options include maximum retries, whether to error if the retry limit is exceeded, and the tracking scope for failures (per-invocation or global).
• Reflection Guidance: When a tool fails and retries are available, the plugin generates detailed reflection guidance to help the tool agent understand and correct its approach.
• Retry Exceeded Messaging: If the maximum retry limit is reached, a specific message is generated instructing the tool agent to cease using the failing tool and devise a new strategy.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

1. why is each line of the message a separate fmt.Printf versus using a big format const string or text/template?
2. can the message be made configurable, much like agents have InstructionProvider? (or Generator, forget off the top of my head)

1. why is each line of the message a separate fmt.Printf versus using a big format const string or text/template?
2. can the message be made configurable, much like agents have InstructionProvider? (or Generator, forget off the top of my head)

+1 to both comments from @verdverm

2nd point could be left to be done later, but if you have the possibility to add this, this would've been perfect!

1. why is each line of the message a separate fmt.Printf versus using a big format const string or text/template?
2. can the message be made configurable, much like agents have InstructionProvider? (or Generator, forget off the top of my head)

+1 to both comments from @verdverm

2nd point could be left to be done later, but if you have the possibility to add this, this would've been perfect!

For the 1 - the main reason I used separate printfs way was to be able to use backticks and use the same exact prompt that adk-python uses, the multiline string does not support `s and I didn't want to create additional files for template texts.

I can make them something like this but I personally find the multiple printfs more readable.

	templateStr := `
The call to tool {{.ToolName}} failed.

**Error Details:**
` + "```" + `
{{.ErrorDetails}}
` + "```" + `

**Tool Arguments Used:**
` + "```" + `json
{{.ArgsSummary}}
` + "```" + `

**Reflection Guidance:**
This is retry attempt **{{.RetryCount}} of {{.MaxRetries}}**. Analyze the error and the arguments you provided. Do not repeat the exact same call. Consider the following before your next attempt:

1.  **Invalid Parameters**: Does the error suggest that one or more arguments are incorrect, badly formatted, or missing? Review the tool's schema and your arguments.
2.  **State or Preconditions**: Did a previous step fail or not produce the necessary state/resource for this tool to succeed?
3.  **Alternative Approach**: Is this the right tool for the job? Could another tool or a different sequence of steps achieve the goal?
4.  **Simplify the Task**: Can you break the problem down into smaller, simpler steps?
5.  **Wrong Function Name**: Does the error indicates the tool is not found? Please check again and only use available tools.

Formulate a new plan based on your analysis and try a corrected or different approach.

Let me know if you have any preferences?

For the 2 - I probably want to do that as a follow up (so thatI can start using this immediately).

Honestly, it's all the operators and function calls that make it unreadable. In example: are those quotes, plus signs, and ticks in the message or not? I have to do far too much mental parsing, gofmt whitespace rules are going to undo any readability whitespace introduced.

I'd personally put the content in a file and then //go:embed it.

My general preference is to align with Go practices over Python for the sake of keeping things visually the same between implementations. As the number of languages increase (there are now 4), it's going to become impossible anyway.

I agree, //go:embed-ing the instructions would make it really neat.

Let me know if it looks good to you and it would be ok to update this, otherwise I could update it later. I don't have a strong preference here.

Thanks!

@verdverm @dpasiukevich PTAL - I moved them into templates as you suggested.

@caglar10ur, lgtm

Clarifying question, these templates are part of the tool response payload the agent sees on the next turn and do not create additional LLM calls, correct? (i.e. there are now additional fields it can pay attention to)

Are there docs on how to use this in my application? (even if for python)

@verdverm correct - the guidance is added to the response so that model can figure out what to do next. That being said using the pluging will cause additional LLM and tool calls. Its purpose is to provide reflection guide to the model for retry.

E.g. Without this plugin you call a tool and it returns some kind of resource exhausted error and agent will probably return the error to you. With the plugin enabled, the plugin will recommend model to understand and course correct, model will think the resource exhausted is not permanent and try calling the tool again.

There is https://google.github.io/adk-docs/integrations/reflect-and-retry/ (but obviously only for python).

ok, the retry is certainly expected, I had wondered before reading closer if those were prompts to some "micro" agent that keeps the retry and extra events out of the main session history and main agent context, which would be cool too