-
Notifications
You must be signed in to change notification settings - Fork 2.2k
feat(spec)!: support arrays and primitives in DataPart
#1306
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Summary of ChangesHello @matoushavlena, 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 significantly enhances the flexibility of the Highlights
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces a significant and breaking change by updating DataPart.data from google.protobuf.Struct to google.protobuf.Value. This enhancement allows DataPart to carry not just JSON objects, but any valid JSON value, including arrays and primitives. The changes are correctly implemented in the protobuf specification, and the accompanying documentation updates in llms.txt, key-concepts.md, and a2a.proto clearly reflect this new capability. I have one minor suggestion to improve the consistency of the documentation update in one of the tutorial files.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Signed-off-by: Matous Havlena <[email protected]>
|
/vote |
Vote created@geneknit has called for a vote on The members of the following teams have binding votes:
Non-binding votes are also appreciated as a sign of support! How to voteYou can cast your vote by reacting to
Please note that voting for multiple options is not allowed and those votes won't be counted. The vote will be open for |
DataPart
Vote statusSo far Summary
Binding votes (1)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
4 similar comments
Vote statusSo far Summary
Binding votes (1)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (1)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (1)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (1)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
|
/check-vote |
|
Votes can only be checked once a day. |
Vote statusSo far Summary
Binding votes (3)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
1 similar comment
Vote statusSo far Summary
Binding votes (3)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (3)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
8 similar comments
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
6 similar comments
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote statusSo far Summary
Binding votes (4)
|
| User | Vote | Timestamp |
|---|---|---|
| holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
Vote closedThe vote passed! 🎉
Summary
Binding votes (5)
|
| User | Vote | Timestamp |
|---|---|---|
| @holtskinner | In favor | 2025-12-11 15:29:29.0 +00:00:00 |
|
This proposal introduces a breaking change at the gRPC/protobuf level, and the associated cost in terms of client updates, regressions, and debugging should not be overlooked. In protobuf, only field numbers are preserved on the wire, not the field definitions. Changing the type of an existing field creates a compatibility gap: a newer client interacting with an older agent (or vice versa) would be unable to reliably interpret DataPart, effectively breaking interoperability of one of the most heavily used field of the whole protocol. Alternative solutions should be considered. For instance, and safer pattern would be to introduce a new field and deprecate the existing one rather than changing it in place. Also, FWIW: We have made a different proposal to allow usage of the gRPC type |
|
@xui-will The latest iteration of the thinking about changes to the Part type are documented in this comment here #1255 (comment) We are moving to a v1.0, which is a breaking change from v0.3. This is an opportunity we need to take before we release v1 and we will not want to make any breaking changes for hopefully a long time. My understanding of |
muscariello
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
@darrelmiller @muscariello I think we can close this in favor of Darrel's PR which refactors Part completely: #1363. This PR switches content.Data to a Value so that it supports arrays / other json primitives. |
Changes
DataPart.datafromgoogle.protobuf.Structtogoogle.protobuf.Valueto support JSON arrays, primitives, and other non-object values.Breaking change: The protobuf field type changes from
StructtoValue. Code that directly accessesDataPart.dataas a struct/map will need to be updated to handle the broaderValuetype, which can be an object, array, string, number, boolean, or null.Resolves #1088
Related #1255