ci: Silence New Lint errors

[holtskinner]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @holtskinner, 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 addresses new linting errors that have appeared, likely due to an update in the Ruff linter or its configuration. The primary goal is to silence these new errors to ensure that continuous integration (CI) pipelines continue to pass without introducing new code changes. This is achieved by updating the global Ruff configuration to ignore a specific error code and by adding inline noqa comments to suppress other specific linting warnings in relevant Python files. The changes do not alter any application logic or behavior, focusing solely on maintaining a clean linting status.

Highlights

• Ruff Configuration Update: The .ruff.toml configuration file was updated to include FIX002 in the ignore list. This change prevents a newly introduced linting error from failing CI builds.
• In-Code Linting Suppression: Several Python files (default_request_handler.py, jsonrpc_handler.py, database_push_notification_config_store.py) were modified to include noqa comments. Specifically, noqa: TRY301 was added to raise ServerError statements and noqa: PERF203 was added to an except ValueError block. These additions suppress specific linting warnings that were likely introduced by an update to Ruff or its rules, ensuring the codebase remains compliant without altering the existing logic.

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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

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 issue 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 silences new lint errors by adding noqa comments and ignoring the FIX002 rule in the ruff configuration. The changes are effective in suppressing the warnings. However, for the TRY301 suppressions, I've added a comment suggesting a potential refactoring of the exception hierarchy. This would address the root cause of the linting error and improve code maintainability in the long run.

[gemini-code-assist]

While adding noqa: TRY301 silences the linter, it's worth considering the underlying reason for the warning. The tryceratops linter flags raising exceptions that are direct subclasses of Exception, encouraging more specific exception hierarchies.

The project already defines A2AServerError which seems intended as a base for application-specific exceptions. However, ServerError inherits directly from Exception.

For better maintainability and a clearer exception hierarchy, consider refactoring ServerError to inherit from A2AServerError in src/a2a/utils/errors.py. This would make ServerError part of a custom exception tree, which is better practice and might allow removing these noqa comments in the future.

As an example, the change in src/a2a/utils/errors.py would look like this:

class ServerError(A2AServerError):
    # ...

This change is outside the scope of this PR, but it would be a valuable future improvement.