[SignalR] Add parameter index to invocation binding exception message

[BrennanConroy]

Updates how argument binding errors are reported to include which argument caused the binding failure, making it easier to diagnose issues when types do not match.

Finally able to get rid of a sticky note I've had on my desk for >3 years.

[Copilot]

Pull Request Overview

This PR enhances SignalR's error reporting by adding parameter index information to invocation binding exception messages. When argument binding fails due to type mismatches, the error message now includes which specific argument caused the failure (e.g., "Error binding argument 1" instead of "Error binding arguments").

• Updates error message format across all SignalR protocol implementations to include argument index
• Modifies loop structures to track the current argument index for error reporting
• Updates corresponding test expectations to match the new error message format

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
MessagePackHubProtocolTestBase.cs	Updates test expectations for MessagePack protocol error messages to include argument index
JsonHubProtocolTestsBase.cs	Updates test expectations for JSON protocol error messages to include argument index
NewtonsoftJsonHubProtocol.cs	Modifies error handling to include parameter index in binding failure messages
MessagePackHubProtocolWorker.cs	Updates loop structure and error message to track and report argument index
JsonHubProtocol.cs	Adds parameter index to binding error messages
GsonHubProtocolTest.java	Updates Java client test expectations for new error message format
GsonHubProtocol.java	Implements argument index tracking in Java client protocol implementation
HubConnectionTests.cs	Updates functional test expectations for new error message format

[DeagleGross]

question: what is the difference between this method and the other (lines 253 and 231)? They have identical signature with exception that one throws exception; is one of them not called at all?

[BrennanConroy]

One takes a JsonArray, the other takes a JsonReader.

The order of Json properties can be random, so if the array of arguments comes before the name of the method we're calling then we store the JsonArray to bind the arguments later, but if it's in the nicer order of (method, arguments) we can directly read the arguments from the JsonReader.

e.g.
{"target": "methodName", "arguments": [1, "blah"]}
vs.
{"arguments": [1, "blah"], "target": "methodName"}