fix: Don't autogenerate message id (0.3 TCK has a test for a null one)

[kabir]

No description provided.

[gemini-code-assist]

Code Review

This pull request refactors several core specification classes in the compat-0.3 module (such as Message_v0_3, Task_v0_3, and various security schemes and parts) from standard classes to Java records. This change updates all getter method invocations to record accessor methods across clients, transports, mappers, and tests. Additionally, a new test infrastructure module tests/server-common is introduced. The review feedback highlights potential NullPointerException risks and validation failures if messageId is null, recommending that messageId be marked as @Nullable in Message_v0_3 and properly null-checked before being set in the protobuf builder in ProtoUtils_v0_3.

[kabir]

/gemini review

[gemini-code-assist]

Code Review

This pull request updates the Message_v0_3 record to allow a null messageId instead of autogenerating a UUID, with corresponding updates to the protobuf utility class and serialization tests. The review feedback highlights two critical inconsistencies: the deserialization logic in FromProto.message still rejects empty message IDs, and the Message_v0_3.Builder.build() method still autogenerates a UUID when the ID is null.

[gemini-code-assist]

Although the record constructor has been updated to allow and preserve a null messageId (instead of autogenerating a UUID), the Message_v0_3.Builder.build() method (around line 146) still autogenerates a UUID if messageId is null:

public Message_v0_3 build() {
    return new Message_v0_3(role, parts, messageId == null ? UUID.randomUUID().toString() : messageId,
            contextId, taskId, referenceTaskIds, metadata, extensions);
}

This makes the builder inconsistent with the record constructor and prevents clients from using the builder to construct a Message_v0_3 with a null messageId. Consider updating the builder to also allow null messageId without autogenerating a UUID.

[kabir]

@gemini-code-assist The record constructor is for internal serialization where a null ID is needed. This is needed since the TCK has a test for null message IDs and we need to be able to to pass this test.

The Builder is more client/user API, and the thinking is to steer them towards having to provide a messageId

[gemini-code-assist]

Thank you for the clarification, kabir. That makes sense given the different requirements for internal serialization versus the public-facing builder API. I understand the design choice to enforce explicit messageId provision for clients.