chore: Evaluate OpenCode performance#377
chore: Evaluate OpenCode performance#377bartek-gralewicz wants to merge 2 commits intoepic/1.0_breaking_changesfrom
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 focuses on significant internal refactoring and API cleanup to enhance the maintainability and clarity of the A2A client and server. The changes aim to improve the consistency of naming conventions and simplify data structures, particularly around task management, streaming, and push notification configurations. These updates lay a foundation for future performance evaluations by ensuring a more coherent and standardized codebase. 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. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces significant refactoring and renaming across the client, server, and transport layers to standardize method names, parameter structures, and type definitions. Key changes include renaming resubscribeTask to subscribeToTask, blocking to returnImmediately, and consolidating push notification configurations under TaskPushNotificationConfig. The API now uses direct id and taskId parameters instead of parsing them from resource names, and REST endpoints have been updated accordingly. The a2a_types.ts file has been removed, indicating a type definition consolidation. A critical typo in test/server/mocks/agent-executor.mock.ts needs to be addressed, and a type assertion in src/client/multitransport-client.ts for TaskPushNotificationConfig could lead to runtime errors if required fields are missing, suggesting a fragile implementation that needs further attention.
| append: false, | ||
| lastChunk: false, | ||
| artifact: undefined, | ||
| 91: undefined, |
src/client/multitransport-client.ts
Outdated
| result.configuration.taskPushNotificationConfig = { | ||
| ...this.config.pushNotificationConfig, | ||
| taskId: params.message.taskId, | ||
| id: this.config.pushNotificationConfig.id || '', // Must have ID? Or server generates it? | ||
| // If config is partial, we assume missing fields are handled by server or not needed? | ||
| // But TaskPushNotificationConfig expects fields. | ||
| // This is tricky if TaskPushNotificationConfig is strict. | ||
| } as TaskPushNotificationConfig; |
There was a problem hiding this comment.
The type assertion as TaskPushNotificationConfig hides a potential issue where this.config.pushNotificationConfig (which is a Partial<TaskPushNotificationConfig>) may not have all the required fields of TaskPushNotificationConfig (like url, token, and tenant). This could lead to runtime errors if the receiving end expects a complete object.
To make this safer, you should validate that the necessary properties exist on this.config.pushNotificationConfig before creating the full object, or ensure the server can handle a partial configuration. The comments in the code suggest awareness of this, but it remains a fragile implementation.
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.Fixes #<issue_number_goes_here> 🦕