Repository navigation
fix: guard against JsonNull when parsing response error field - #858
Conversation
RainYuY
changed the title
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the JSON-RPC response parsing in JSONRPCUtils.java to handle cases where the 'error' field is present but null. The review feedback suggests optimizing this logic by retrieving the 'error' element once to avoid multiple lookups and recommends applying this pattern consistently to other similar methods like parseResponseEvent.
There was a problem hiding this comment.
The current implementation performs multiple lookups for the 'error' field. A more efficient approach is to retrieve the element once. Since the JSON-RPC specification defines the error field as an object, we can rely on this constraint and avoid additional defensive type checks for primitives. This same pattern should be applied to parseResponseEvent at line 293.
JsonElement errorNode = jsonRpc.get("error");
if (errorNode != null && !errorNode.isJsonNull()) {
return parseError(errorNode.getAsJsonObject(), id, method);
}References
- When handling return types constrained by a formal specification, it is acceptable to rely on the specification's constraints rather than adding defensive checks for types that the specification explicitly excludes.
…ject#858) * fix: guard against JsonNull when parsing JSONRPC error field * Refactor error handling in JSONRPCUtils
2 participants
Description
Root Cause
The serializer and deserializer are inconsistent:
The correct long-term fix is to also stop emitting "error": null in
A2AErrorTypeAdapter.write(), but this client-side guard is sufficient to
prevent the crash.
Impact
Without this fix, every non-streaming A2A call fails with ClassCastException
regardless of whether the response is actually an error.
Thank you for opening a Pull Request!
Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
CONTRIBUTINGGuide.fix:which represents bug fixes, and correlates to a SemVer patch.feat:represents a new feature, and correlates to a SemVer minor.feat!:, orfix!:,refactor!:, etc., which represent a breaking change (indicated by the!) and will result in a SemVer major.Fixes #<issue_number_goes_here> 🦕