Status code · Data access
BadRequestTooLarge
BadMessage limits
BadRequestTooLarge means the server refused your request because its encoded size exceeded the server's receive limit. Split the operation into smaller batches sized from Server_ServerCapabilities_OperationLimits, rather than raising limits. Browse, Read, Write and CreateMonitoredItems batches are the usual offenders.
Defined behaviour: The request message size exceeds the limits set by the server. (our description of the condition this code reports)
What you actually see
A bulk Read, Write or CreateMonitoredItems fails outright with no per-item results, while the same operation split into halves succeeds.
Why it happens
- Batch size far above the server's operation limitsServers publish MaxNodesPerRead, MaxNodesPerWrite, MaxNodesPerBrowse and MaxMonitoredItemsPerCall in the ServerCapabilities OperationLimits object. Exceeding those is often reported as too many operations, but a batch that is merely large in bytes - long string NodeIds, many IndexRanges - hits the size limit first.
- Long string or GUID NodeIds inflating the requestA thousand numeric NodeIds encode compactly. A thousand string NodeIds with a deep browse-path-style identifier can be an order of magnitude larger. The item count looks reasonable while the encoded size is not, which is why the same batch size works on one server and fails on another.
- Writing large array or ByteString valuesA single Write carrying a large array, an image or a file chunk can exceed the server's receive buffer on its own. This one is not fixed by batching - it needs a smaller payload or a file transfer mechanism.
- Server receive buffer smaller than the client assumedThe Hello and Acknowledge exchange negotiates buffer sizes per direction. An embedded server may advertise a small receive buffer, and a client that ignores the acknowledged value and uses its own configured maximum will overshoot.
- Chunk count limit rather than byte limitEven where the total size is acceptable, MaxChunkCount caps how many chunks a single message may occupy. A large request against a server with a small chunk size and a low chunk count is refused on chunk count, reported the same way.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Read the server's operation limitsBrowse Server_ServerCapabilities_OperationLimits and read MaxNodesPerRead, MaxNodesPerWrite, MaxNodesPerBrowse, MaxMonitoredItemsPerCall and the related properties. Where a property is absent or zero the server declares no limit, which is not the same as an unlimited buffer.
- Chunk the operation and retrySplit into batches well below the published limit - a few hundred nodes is a safe starting point on most servers - and process them sequentially. Sequential batches also make per-item failures far easier to attribute.
- Check what the Acknowledge actually grantedLog the negotiated ReceiveBufferSize, SendBufferSize, MaxMessageSize and MaxChunkCount from the Hello and Acknowledge exchange. If the server granted less than the client asked for, the client must respect the granted value.
- Shorten identifiers where you control the modelString NodeIds carrying full hierarchical paths are convenient and expensive. Use RegisterNodes for hot nodes so subsequent operations carry compact server-assigned handles instead of long identifiers.
- Move very large values off the Read and Write pathFor file-sized payloads use the FileType interface with Read and Write calls sized to the server's chunk expectations, or take an offline NodeSet2 export. A single oversized Write is the wrong shape for the transport.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| asyncua (Python) | Read Server_ServerCapabilities_OperationLimits and chunk explicitly - asyncua sends whatever list you hand it. A helper that slices node lists into fixed batches is worth writing once and reusing. |
| UA-.NETStandard (C#) | The Session class exposes OperationLimits populated at connect from the server. Honour Session.OperationLimits.MaxNodesPerRead rather than hard-coding, and set TransportQuotas to match what the server acknowledged. |
| node-opcua | Large browse or read arrays are sent as one request. Use the client's operationLimits, populated from the server, to slice the array before calling read or browse. |
| open62541 (C) | Client and server both carry a localConnectionConfig with recvBufferSize, sendBufferSize, maxMessageSize and maxChunkCount. The acknowledged values, not the configured ones, govern - inspect them after connect. |
| UaExpert | Adding a very large node set to the Data Access View in one go can produce this on constrained servers. Add nodes in groups; the failure is a server limit, not a UaExpert defect. |
| OPC Publisher | A large published nodes configuration is applied as batched CreateMonitoredItems calls. If the batch size exceeds the server limit the whole batch fails, so reduce the configured batch size rather than the number of published nodes. |
What it looks like in the log
ServiceFault: BadRequestTooLarge on Read with 4000 nodes
Request rejected - encoded size 3.2 MB exceeds server receive buffer
Acknowledge granted ReceiveBufferSize=65536, MaxChunkCount=8Confirm the fix
Run the same total workload as sequential batches and confirm every batch returns Good, then check that the per-item status arrays are complete and none of the items were silently dropped.
Stop it happening again
Derive batch sizes at runtime from Server_ServerCapabilities_OperationLimits and the acknowledged buffer sizes, and use RegisterNodes for repeatedly accessed nodes so recurring requests stay compact.
Related status codes
Concepts on this page
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.