fix(jsonrpc): avoid NumberFormatException on every SSE event for string request IDs - #1254

I think this needs two changes before merging:

1. Valid string IDs outside the integer range now fail parsing. In getAndValidateId(), INTEGER_STRING_PATTERN matches IDs such as "2147483648" and "1700000000000", but the subsequent Integer.parseInt(raw) throws an uncaught NumberFormatException. Previously these were returned as strings by the fallback. I reproduced the regression through both parseRequestBody() and parseResponseEvent() using the PR source.

2. Numeric strings should remain strings, as agreed in [Bug]: JSONRPCUtils.getAndValidateId throws and catches NumberFormatException for every SSE event when id is a string (client default) #1253. My issue comment asked for numeric string IDs such as "123" to be preserved as strings, with the existing tests updated accordingly. The PR instead retains the integer conversion and adds a test requiring it. That conversion also loses the original representation of IDs such as "00123".

Please use the primitive type check proposed in the issue:

JsonPrimitive primitive = jsonRpc.getAsJsonPrimitive("id");
id = primitive.isNumber() ? primitive.getAsInt() : primitive.getAsString();

This removes the exception cost for UUID IDs and preserves all string IDs without parsing them as integers. Please update the numeric-string test to expect a String, adjust any existing expectations, and add coverage for a numeric string outside the integer range.

The PR's 52 tests passed when compiled and run against local dependencies; the additional probes exposed the regression above.

Also you need to rebase on the current state of the main branch

Thanks @kabir — both issues addressed in the updated commit:

1. Simplified to your suggested one-liner: primitive.isNumber() ? primitive.getAsInt() : primitive.getAsString() — no pattern matching, no parseInt, no overflow risk.
2. Updated existing tests that were asserting numeric string IDs (e.g. "1", "2", "5") returned Integer — those now correctly expect String. Added four regression tests covering UUID string, numeric string, out-of-range numeric string ("2147483648"), and JSON number literal.

Also rebased onto current main.

The code changes look good now, thanks. Could you also update the PR description? It still describes the regex approach and says numeric string IDs are converted to integers.

Please describe the primitive type check, clarify that all string IDs remain strings, and update the test summary to include the out-of-range numeric string case and the 54 passing tests.

Done @kabir — PR description updated to reflect the primitive type check, clarify that all string IDs remain strings, and include the out-of-range numeric string test case and the 54 passing tests.

Thanks @sumitvairagar !