BadTooManyArguments
BadMethod calls
BadTooManyArguments means your Call sent more inputArguments than the method's InputArguments property declares. The argument list is positional and fixed-length, so extras are an error rather than being ignored. Read InputArguments and truncate your list to exactly the declared count and order.
What you actually see
A method call that used to work now fails after a client update or a server downgrade, with no change to the values being sent.
Why it happens
- Client built against a newer model versionCompanion-spec methods gain arguments over releases. A client written for the newer signature sends the extra argument to a server still implementing the earlier one. The mirror image of BadArgumentsMissing, and it usually appears when a fleet has mixed firmware.
- Output arguments appended to the input listMethods declare InputArguments and OutputArguments as separate properties. Code that reads one combined list, or that reserves slots for return values, sends the outputs as extra inputs.
- A Structure argument flattened into membersA single Structure input expanded into its constituent fields inflates the argument count. When the flattened count exceeds the declared count you get this code; when it is lower you get BadArgumentsMissing, which is why the two often alternate during debugging.
- Array argument passed as separate elementsAn input declared with a ValueRank of one is one argument holding an array. Passing each element as its own argument sends many arguments where one was expected.
- Framework helper adding a context or session parameterWrappers that inject a context object, a timeout or a session handle into the call signature can leak it into the wire arguments if the wrapper is misused. Log the actual serialised argument count to see this.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Read InputArguments and count itBrowse the Method node's HasProperty reference to InputArguments and read the Argument array. Its length is the only legal argument count. Log both the declared and the sent count at the call site while diagnosing.
- Separate inputs from outputs in your codeRead OutputArguments as well and confirm your extras are not simply the outputs. Outputs come back in CallMethodResult.outputArguments; you never send space for them.
- Send Structures and arrays as single argumentsEncode a Structure input as one ExtensionObject and an array input as one Variant holding the array. Confirm the declared DataType and ValueRank from the Argument entry rather than guessing from the argument name.
- Pin the model version per serverRead the model or software version the server reports and select the matching call signature. In a mixed fleet, branch on that rather than sending a superset and hoping servers ignore extras, which they will not.
- Assert the count in one wrapperPut a single guard in your call helper that compares the built argument array length against the cached declared length and raises a clear local error. That converts a wire failure into a configuration error you can act on.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| node-opcua | getArgumentDefinition returns inputArguments and outputArguments distinctly. Building the call from the concatenation of both is a real and easy mistake to make when iterating the result object. |
| asyncua (Python) | call_method takes varargs, so an extra value in a splatted list is invisible at the call site. Build the argument tuple from the read Argument array and its length rather than from a literal. |
| UA-.NETStandard (C#) | session.Call with a params array accepts any count. Wrap it with a helper that validates against the cached Argument array; the SDK will not do this for you. |
| open62541 (C) | The inputSize argument to UA_Client_call is where an off-by-one lands, typically when a loop bound is reused from an output array. |
| UaExpert | The Call dialog can only send the declared count, so it is a reliable control: if UaExpert succeeds, your client is sending extras and the method itself is fine. |
What it looks like in the log
Call ns=4;i=7112 -> BadTooManyArguments (sent 4, declared 3)
InputArguments length=3, OutputArguments length=2, client sent 5Confirm the fix
The call returns a Good CallMethodResult statusCode with the expected outputArguments, and the logged sent count equals the declared count. Test against each firmware or model version present in the fleet.
Stop it happening again
Build argument lists from the server's declared Argument array, keep input and output handling strictly separate, and version your call signatures per server model version rather than assuming one shape across a mixed fleet.
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.