draft not for review. prototype showing retry messages

[jacob314]

• UI showing slow responses
• Hacks to simulate slow responses.

Summary

Details

Related Issues

How to Validate

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 @jacob314, 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 prototypes and implements the display of retry messages within the application's UI, providing immediate feedback to the user during transient errors or slow server responses. It involves integrating a retry counter into the UI state, visually updating loading indicators, and introducing robust simulation mechanisms for testing retry scenarios in various content generation services.

Highlights

• UI for Retry Messages: The UI now displays a 'Transient error. Retrying...' message with a warning color when a retry attempt is in progress. This is driven by a new retryCount in the UI state.
• Retry Count Management: A retryCount state has been introduced in useGeminiStream to track active retry attempts. This count is reset on successful content generation or new queries and updated when CoreEvent.Retry is emitted.
• Simulated Slow Responses and 429 Errors: New utility functions (shouldSimulateSlowServer, shouldSimulate429, createSimulated429Error) have been added and integrated into content generators (CodeAssistServer, FakeContentGenerator, LoggingContentGenerator) to allow for simulating slow server responses and HTTP 429 (Too Many Requests) errors for testing and prototyping retry behavior.
• Enhanced Retry Logic: The core retryWithBackoff utility now emits CoreEvent.Retry on each failed attempt, includes an onRetry callback, and has its default maxAttempts increased from 3 to 10. It also calls resetSlowServerSimulation on success.
• Spinner Color Customization: The GeminiRespondingSpinner and GeminiSpinner components now accept a color prop, allowing the retry indicator to be dynamically colored (e.g., warning yellow).

🧠 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.

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. ↩

[github-actions]

Size Change: +5.8 kB (+0.03%)

Total Size: 22 MB

Filename	Size	Change
./bundle/gemini.js	22 MB	+5.8 kB (+0.03%)

ℹ️ View Unchanged

Filename	Size
./bundle/sandbox-macos-permissive-closed.sb	1.03 kB
./bundle/sandbox-macos-permissive-open.sb	890 B
./bundle/sandbox-macos-permissive-proxied.sb	1.31 kB
./bundle/sandbox-macos-restrictive-closed.sb	3.29 kB
./bundle/sandbox-macos-restrictive-open.sb	3.36 kB
./bundle/sandbox-macos-restrictive-proxied.sb	3.56 kB

_{compressed-size-action}

[gemini-code-assist]

Code Review

This pull request introduces a UI feature to display retry attempts for network requests, which is a great enhancement for user experience by providing more transparency during transient network issues. The implementation involves adding a retryCount state that is propagated from the core retryWithBackoff utility up to the UI components. The LoadingIndicator is updated to show a warning message and change color during retries. The changes are well-structured, with updates to hooks, contexts, and components to support this new feature. Test utilities to simulate slow responses have also been added, which is useful for prototyping.

My main feedback is a high-severity concern regarding the increase of the default maximum retry attempts from 3 to 10. This could lead to users waiting for several minutes for the CLI to recover, which might be a frustrating experience.

[gemini-code-assist]

The default maxAttempts for retries has been increased from 3 to 10. While this increases resilience to transient errors, it can also lead to a very long wait time for the user.

With an initial delay of 5s, a multiplier of 2, and a max delay of 30s, the total wait time for 9 retries could be over 3.5 minutes:
5s + 10s + 20s + 6 * 30s = 215s

This long duration might be perceived as the application being hung, leading to a poor user experience. Additionally, it could mask more persistent underlying network or service issues.

Consider whether this long retry duration is intended. A lower number of retries (e.g., 5) might offer a better balance between resilience and user experience. If a higher number is desired, it might be better to make it configurable by the user.