Backports to 0.3.x CI

[kabir]

Just to get CI. We will merge these directly to avoid the annoying squashing

[gemini-code-assist]

Summary of Changes

Hello @kabir, 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 incorporates a series of backported changes to the 0.3.x branch, primarily aimed at enhancing the stability and correctness of task management functionalities. Key updates include standardizing the historyLength parameter to a non-nullable integer, implementing a more robust metadata merging strategy, and refining the process of managing task message history. These adjustments are crucial for maintaining a healthy Continuous Integration environment for the 0.3.x branch.

Highlights

• History Length Parameter Refactor: The historyLength parameter across various components, including TaskQueryParams, GrpcTransport, and RestTransport, has been refactored from a nullable Integer to a primitive int. This change simplifies logic by removing null checks and standardizing its default value to 0.
• Metadata Merging in TaskManager: The TaskManager now intelligently merges new metadata with existing task metadata when processing TaskStatusUpdateEvents, rather than overwriting it. This ensures that all relevant metadata is preserved and combined.
• Refined Task History Management: The updateWithMessage method in TaskManager has been improved to correctly handle the flow of messages into task history. It now ensures that the current status message is added to the history before a new message is appended, and then clears the current status message.
• CI Backports for 0.3.x Branch: These changes are explicitly backported to the 0.3.x branch with the primary goal of ensuring the Continuous Integration (CI) pipeline functions correctly and smoothly for this specific release line.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/run-tck.yml

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 backports several changes, primarily focused on refactoring the historyLength parameter in TaskQueryParams from Integer to a primitive int. This simplifies the logic and improves robustness by eliminating null checks. The changes are propagated consistently across the gRPC and REST transports, request handlers, and tests. Additionally, there are improvements to metadata handling in TaskManager to merge instead of overwrite, and a fix to correctly move messages from TaskStatus to the history. I've found one potential issue in the history trimming logic that seems to be an unintended side effect of these changes.

[gemini-code-assist]

When params.historyLength() is 0, it seems more correct to return an empty history list as was done previously, rather than the full task history. A historyLength of 0 typically implies that no history items are requested. This change alters the API behavior for clients that explicitly request 0 history items, as they will now receive the entire history.

Suggested change

	history = task.getHistory();
	history = new ArrayList<>();

[kabir]

Merged manually