Repository navigation
[Bug]: Response Stream Array-Wrapping Crash (Transport Layer Mismatch) #1089
Description
What happened?
This is continuation from #1074 as splitting into two issues are suggested by @ishymko
Copied the issue description below for context
Response Stream Array-Wrapping Crash (Transport Layer Mismatch)
By default, Google wraps streaming RPC responses (Flow<StreamResponse>) inside a JSON array [ {"task": ...} ] to frame stream chunk boundaries on the wire.
- The Mismatch: The SDK's legacy compatibility transport (
CompatRestTransportinsidea2a/compat/v0_3/rest_transport.py) fails to request standard SSE transcoding from Google because it does not append the standard?alt=ssequery parameter to the stream endpoint URL. This forces Google to fall back to default plain JSON array-wrapped streams. - The Crash: Standard transports in
a2a/client/transports/rest.pyparse stream events using standardParse(fromgoogle.protobuf.json_format):Because standardevent: StreamResponse = Parse(sse_data, StreamResponse())
Parsestrictly expects a single JSON object{...}, the leading and trailing array brackets ([and]) causejson_format.Parseto crash immediately on the very first chunk:google.protobuf.json_format.ParseError: Failed to parse {'task': {...}} field: unhashable type: 'dict'.
Thanks for pointing this issue is not specific to v0.3 but v1 as well. Regarding the workaround mentioned in #1074 (comment) , yes it will work with the workaround but this mean all the customer/developer who integrated with Google A2A APIs will require this workaround introduces developer friction. Is there any way we could make this smoother so developer can use SDK with Google A2A API out of the box? Thanks!
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
rohityan commentedon Jun 4, 2026
Hi @xtan999 , thanks for creating a separate issue for this concern. As @ishymko suggested the preferred method would be to fix it on server side. Meanwhile you could continue using the workaround as detailed in #1074 .
rohityan commentedon Jun 4, 2026
Hi @ishymko , PTAL.
ishymko commentedon Jun 8, 2026
Hey @xtan999, thanks for creating a separate issue!
Yeah this is true, while still it doesn't feel right to me to always hardcode
?alt=ssewhile it's required for Google transcoding only.WDYT about packaging this interceptor from a workaround into an opt-in thing which can be added with 1-2 lines and documenting it? This way we will utilize existing extension points and won't "pollute" the API (as another alternative would be to add a flag for instance for
RestTransport).xtan999 commentedon Jun 15, 2026
Hi @ishymko,
Thanks for sharing the alternatives! I think any way that doesnt require user to write additional custom client code/interceptor for handling Google API would be good! Since you have more context, I will leave you to decide which option is more appropriate for the SDK.
github-actions commentedon Jun 29, 2026
isheng-eqi commentedon Jul 7, 2026
Submitted PR #1124 addressing this — adds an opt-in
extra_paramsoption toRestTransportandCompatRestTransportthat threads throughClientConfig. Usage:ClientConfig(extra_params={'alt': 'sse'}). PTAL @ishymkofix: add SSE parameter and content alias for v0.3 compat streaming
fix: add SSE parameter and content alias for v0.3 compat streaming
fix: add SSE parameter and content alias for v0.3 compat streaming
fix: add SSE parameter and content alias for v0.3 compat streaming