feat(compat): AgentCard backward compatibility helpers and tests#760
feat(compat): AgentCard backward compatibility helpers and tests#760
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! 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 robust backward compatibility mechanisms for Agent Cards, enabling smooth communication between systems using different protocol versions (v0.3 and v1.0). By providing dedicated helpers for both parsing incoming legacy cards and serializing current cards for older clients, it ensures that the system can gracefully handle the transition and maintain interoperability without breaking existing integrations. Highlights
Changelog
Activity
Using Gemini Code AssistThe 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
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 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
|
There was a problem hiding this comment.
Code Review
This pull request introduces backward compatibility helpers for v0.3 Agent Cards, allowing them to be used with the v1.0 protocol. The changes include both client-side parsing of legacy cards and server-side serialization to include legacy fields for older clients. The implementation is robust and accompanied by an excellent set of unit and integration tests, including cross-version validation against an older SDK version.
My review focuses on improving type safety in the new compatibility helpers. I've suggested a more specific type hint. Overall, this is a high-quality contribution that significantly improves interoperability.
Note: Security Review did not run due to the size of the PR.
a95abdd to
41bf29c
Compare
There was a problem hiding this comment.
To the best of my knowledge snake_case shouldn't be required here, both 1.0 and 0.3 use camelCase for field names.
| 'schemes': { | ||
| scheme_name: {'list': scopes} | ||
| for scheme_name, scopes in sec_dict.items() | ||
| } |
There was a problem hiding this comment.
What's the source of schemes key here?
Note that in 0.3 the actual data model used is JSON Schema based, not proto based (and have some differences).
| case GetExtendedAgentCardRequest(): | ||
| handler_result = ( | ||
| await self.handler.get_authenticated_extended_card( | ||
| request_obj, | ||
| context, | ||
| ) | ||
| ) |
There was a problem hiding this comment.
Given that compat mode was applied in REST, I believe it should be applied here as well. It happens after version negotiation though, so it doesn't have to be a "union", can be handled in follow-up PR(s) for other conversions.
There was a problem hiding this comment.
nit: if it meant to be committed maybe some short readme on how to use it? We can skip if in the end (after compat work) it's going to be removed completely and fully replaced with automated tests.
This commit implements the backwards compatibility helpers for exchanging legacy v0.3 Agent Cards across the v1.0 protocol bounds.
41bf29c to
f573741
Compare
This commit implements the backwards compatibility helpers for exchanging legacy v0.3 Agent Cards across the v1.0 protocol bounds.
Also resolves linting and validation constraints.
Description
Thank you for opening a Pull Request!
Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
CONTRIBUTINGGuide.fix:which represents bug fixes, and correlates to a SemVer patch.feat:represents a new feature, and correlates to a SemVer minor.feat!:, orfix!:,refactor!:, etc., which represent a breaking change (indicated by the!) and will result in a SemVer major.bash scripts/format.shfrom the repository root to format)