Skip to content

fix: avoid setting Part.partMetadata when metadata is empty - #1439

Open
hemasekhar-p wants to merge 1 commit into
google:mainfrom
hemasekhar-p:issue1421-fix
Open

fix: avoid setting Part.partMetadata when metadata is empty#1439
hemasekhar-p wants to merge 1 commit into
google:mainfrom
hemasekhar-p:issue1421-fix

Conversation

@hemasekhar-p

Copy link
Copy Markdown
Contributor

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

Problem:
In PartConverter.java, toGenaiPart() and convertFilePartToGenAiPart() unconditionally set Part.Builder#partMetadata(...) whenever the A2A part's metadata map was non-null (textPart.getMetadata() != null and filePart.getMetadata() != null). Because PartConverter.fromGenaiPart() initializes A2A parts with default empty metadata maps ({}), any round-tripped or converted A2A message attached empty metadata {} to Part#partMetadata.

Solution:

  1. Updated PartConverter#toGenaiPart (for TextPart) to only call partBuilder.partMetadata(...) when textPart.getMetadata() != null && !textPart.getMetadata().isEmpty().
  2. Updated PartConverter#convertFilePartToGenAiPart (for FileWithUri and FileWithBytes) to check metadata != null && !metadata.isEmpty() before calling builder.partMetadata(metadata).
  3. Added unit tests in PartConverterTest to verify that TextPart and FilePart with empty metadata maps do not set Part.partMetadata.

Testing Plan

Please describe the tests that you ran to verify your changes. This is required
for all PRs that are not small documentation or typo fixes.

Unit Tests:

  • I have added or updated unit tests for my change.
  • All unit tests pass locally.

Checklist

  • I have read the CONTRIBUTING.md document.
  • My pull request contains a single commit.
  • I have performed a self-review of my own code.
  • I have commented my code, particularly in hard-to-understand areas.
  • I have added tests that prove my fix is effective or that my feature works.
  • New and existing unit tests pass locally with my changes.
  • I have manually tested my changes end-to-end.
  • Any dependent changes have been merged and published in downstream modules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

1 participant