Skip to content

fix(jsonrpc): prefer a populated content key when decoding a Part - #1061

Open
rmlopes wants to merge 1 commit into
a2aproject:mainfrom
rmlopes:fix-part-empty-content-key-discriminator
Open

fix(jsonrpc): prefer a populated content key when decoding a Part#1061
rmlopes wants to merge 1 commit into
a2aproject:mainfrom
rmlopes:fix-part-empty-content-key-discriminator

Conversation

@rmlopes

@rmlopes rmlopes commented Aug 13, 2026

Copy link
Copy Markdown

Summary

  • Prefer populated flattened Part content keys over empty-string placeholders.
  • Preserve deliberately empty text parts via a document-order fallback.
  • Reject non-string values for string-backed content keys.
  • Add regression coverage for data, URL, raw, null, empty, falsy, and key-order cases.

Root cause

The discriminator selected the first recognized non-null content key. Some protobuf JSON producers emit every flattened oneOf key and represent unset strings as "", causing an empty placeholder to hide the populated payload.

Validation

  • Added and ran focused regression tests in PartSerializationTest.

This fixes #1062

@rmlopes
rmlopes marked this pull request as ready for review August 13, 2026 01:05
The discriminator scan took the first content key that was merely non-null, so a
producer that emits every key of the flattened oneOf with the unset ones as ""
lost its payload to whichever empty placeholder came first on the wire. The
comment above it already promised "skipping null/empty values"; only null was
ever skipped.

This fixes a2aproject#1062
@rmlopes
rmlopes force-pushed the fix-part-empty-content-key-discriminator branch from c0082af to 54a1516 Compare August 13, 2026 01:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Part decoding discards a populated content key when an empty placeholder precedes it

1 participant