fix: An exception in calling the plugin caused the coroutine pool to be full, triggering a 504 error

[devenami]

Description

return error when invoke plugin error

Fixes #483

Type of Change

• Bug fix
• New feature
• Refactor
• Performance improvement
• Other

Essential Checklist

Testing

• I have tested the changes locally and confirmed they work as expected
• I have added unit tests where necessary and they pass successfully

Bug Fix (if applicable)

• I have used GitHub syntax to close the related issue (e.g., Fixes #123 or Closes #123)

Additional Information

more information link to #483

[gemini-code-assist]

Summary of Changes

Hello @devenami, 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 resolves a critical bug where failures during plugin invocation were not properly handled, leading to resource exhaustion and 504 errors. The changes introduce robust error propagation by updating the PluginRuntime interface and its implementations to return errors from write operations, ensuring that the system can gracefully respond to plugin communication issues and prevent cascading failures.

Highlights

• Error Propagation: The core change involves modifying the Write methods across various plugin runtime implementations and the PluginRuntime interface to return an error. This ensures that errors occurring during plugin communication are properly captured and propagated.
• Consistent Error Handling: All concrete implementations of PluginRuntime (Remote, Local, and Serverless) now return errors from their Write methods, allowing upstream callers like GenericInvokePlugin and Session.Write to handle these failures.
• Bug Fix for Coroutine Pool Exhaustion: This fix directly addresses the issue where unhandled exceptions during plugin invocation could lead to the coroutine pool becoming full and triggering 504 errors, by ensuring errors are returned and can be managed.

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 a critical bug where unhandled exceptions during plugin calls could exhaust the coroutine pool, leading to 504 errors. The core of the fix involves modifying the Write method signature across various plugin runtime implementations to return an error, which is then propagated up the call stack. This change ensures that write failures are communicated to the caller, allowing for proper error handling and resource cleanup. The implementation is consistent and well-executed across the local, remote, and serverless runtimes. I have one minor suggestion to improve logging practices in the serverless runtime implementation.

[tobegit3hub]

Thanks for the contribution and we have the similiar issue which is resolved by this PR.

[Yeuoly]

Hi, sorry for the late review, I've been in a business trip for 2 weeks, the latest release should already fix this issue, please have a review on it @tobegit3hub @devenami .

Of course you can have a review on the #499 to see if the key point has been solved.