BadResponseTooLarge
BadMessage limits
BadResponseTooLarge means the answer the server assembled will not fit inside the negotiated message limits. Reduce what you ask for: fewer nodes per Read, MaxReferencesPerNode with BrowseNext, MaxNotificationsPerPublish on subscriptions, and continuation points on HistoryRead. Raising client buffers is the second resort.
What you actually see
A Browse of a large folder, a HistoryRead over a long window, or a Publish during a burst fails while the same call over a smaller scope returns normally.
Why it happens
- Browse of a node with very many referencesA folder containing thousands of children produces a BrowseResult whose references array does not fit. MaxReferencesPerNode exists precisely to bound this, and a Browse issued with zero - meaning no limit - invites the failure.
- HistoryRead over too wide a windowRaw history over hours at a fast sample rate is a large array of DataValues. NumValuesPerNode and continuation points bound it; asking for an unbounded time range in one call does not.
- Publish response carrying a notification burstWhen many monitored item queues drain in the same publishing cycle the NotificationMessage can exceed the limit. This correlates with process events, restarts and any moment when deep queues flush together, so it looks intermittent.
- Bulk Read of large arraysFifty nodes each holding a thousand-element array is a small request and a very large response. Item count is a poor proxy for response size when array-valued nodes are involved.
- Client receive buffer smaller than the server assumedThe client advertises its receive buffer in the Hello. A client configured conservatively - common in embedded and container images built from defaults - constrains every response the server may send, even on a capable server.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Bound the request that produced the responseSet MaxReferencesPerNode on Browse and follow with BrowseNext. Set NumValuesPerNode on HistoryRead and follow continuation points. Reduce the node count on Read. The response size is a consequence of the request, so that is where to intervene.
- Set MaxNotificationsPerPublish on every subscriptionThis caps how much a single Publish response may carry and lets the server spread a burst over consecutive responses. Combine with bounded QueueSize so a burst does not accumulate in the first place.
- Check the negotiated buffer sizesLog the acknowledged ReceiveBufferSize, MaxMessageSize and MaxChunkCount. If the client asked for a small receive buffer, the server cannot exceed it no matter how it is configured.
- Treat array-valued nodes separatelySplit reads so array-valued nodes are fetched in small groups or individually, and keep the scalar bulk reads batched. Mixing them in one batch makes the size unpredictable.
- Raise client limits only after bounding the requestIncreasing MaxMessageSize and MaxArrayLength on the client is legitimate for genuinely large single values, but it does not solve a burst problem and it moves memory pressure into the client.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | TransportQuotas on the client governs what the server may send back. Subscription.MaxNotificationsPerPublish is settable per subscription and is the correct control for notification bursts. |
| node-opcua | maxNotificationsPerPublish is a CreateSubscription parameter. For browsing, use browseAll or an explicit browseNext loop rather than a single browse with no reference limit. |
| asyncua (Python) | Subscription creation parameters include max_notifications_per_publish. For history, use read_raw_history with a bounded numvalues and follow continuation points rather than requesting a whole shift in one call. |
| open62541 (C) | The client's recvBufferSize and maxMessageSize bound every response. On constrained targets these defaults are small, so a browse of a large folder fails on the client side before the server is at fault. |
| UaExpert | Browsing a very large folder can produce this in the Log view. Expand in stages, or use the server's own structure - a type-driven traversal - rather than pulling an entire branch at once. |
| OPC Publisher | Notification bursts from many monitored items on a single subscription are the common trigger. Lower the batch of items per subscription and set a notification cap rather than increasing message limits. |
What it looks like in the log
ServiceFault: BadResponseTooLarge on Browse of ns=2;s=Plant.Line1
Publish response would exceed MaxMessageSize; reduce MaxNotificationsPerPublish
HistoryRead returned BadResponseTooLarge for a 12 hour raw windowConfirm the fix
Repeat the bounded call and confirm it returns Good with a continuation point where one is expected, then walk the continuation to prove the full result set is reachable in pages.
Stop it happening again
Always set MaxReferencesPerNode, NumValuesPerNode and MaxNotificationsPerPublish in client configuration templates. Size subscriptions so a simultaneous drain of every queue still fits inside one publish response.
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.