BadTooManyPublishRequests
BadPipelining
BadTooManyPublishRequests is the server telling you to reduce the number of outstanding Publish requests. Publish is a long poll, so clients pipeline several to avoid gaps, and servers cap how many they will hold. Cap your outstanding count - commonly two or three per subscription - rather than scaling it with item count.
What you actually see
A client that works against one server logs this code steadily against another, sometimes alongside occasional gaps in data, while everything else about the session behaves normally.
Why it happens
- Client pipelining more Publishes than the server allowsTo avoid a window where no Publish is waiting, clients keep several outstanding. Different servers permit very different numbers, and some are strict. A client tuned against a permissive server will be refused by a stricter one with no other symptom.
- Outstanding count scaled with subscriptions or itemsSome clients issue one or more Publishes per subscription. With a subscription per publishing interval and many intervals, the outstanding total climbs quickly. The fix is a session-wide cap, not a per-subscription one.
- Slow notification handling causing the client to over-issueWhere the client's own processing is behind, its publish manager can respond by issuing more requests in the belief that the server is slow. That makes the situation worse and turns a client-side bottleneck into a server-side rejection.
- Backoff logic the server does not tolerateSome stacks respond to this code by gradually reducing their outstanding count, which works with most servers but not all. Where a server refuses persistently rather than adapting, a hard client-side cap is needed instead of a gradual approach.
- Very long publishing intervals with aggressive pipeliningWith a ten second publishing interval, several outstanding Publishes sit at the server for a long time each, occupying its queue. A modest pipeline depth is appropriate for fast intervals and excessive for slow ones.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Set a hard cap on outstanding Publish requestsConfigure the client's maximum outstanding Publish count explicitly rather than leaving it dynamic. Two or three per session is enough to keep the pipeline full for typical publishing intervals. Do not compute it from the number of monitored items.
- Treat the code as a signal, not an error to retryDo not immediately reissue the refused Publish. Decrement your target outstanding count, let the requests already at the server complete, and settle at the level the server accepts. Reissuing on rejection produces a loop that keeps the server at its cap.
- Fix the client-side handler before touching the pipelineMeasure how long your notification callback takes. If it does database or network work inline, hand notifications to a queue and return immediately. A fast handler needs less pipelining because each Publish is reissued promptly.
- Reduce the number of subscriptionsCollapsing many publishing intervals into a few reduces the number of subscriptions and therefore the number of Publishes in flight if your client pipelines per subscription. This has the useful side effect of relieving subscription and item limits at the same time.
- Confirm no data was lostA refused Publish is not lost data, but check for sequence gaps in the notification stream and use Republish to recover any missing NotificationMessage where your client supports it. Rely on sequence numbers rather than on the absence of errors.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | The stack backs off its outstanding Publish count when it sees this code, but that gradual behaviour is not tolerated by every server, so setting an explicit maximum on the session is often necessary rather than relying on the adaptive path. |
| OPC Publisher | This is a known operational condition documented as the server asking you to reduce outstanding Publishes; a hard cap is the reliable remedy where the adaptive backoff is refused. |
| node-opcua | The publish engine maintains a target number of pending Publish requests. Lower it explicitly for strict servers rather than letting it grow with subscription count. |
| asyncua (Python) | The publish loop keeps a small number of requests in flight. If you have wrapped it, ensure your wrapper does not reissue on this specific code, which is the usual way a loop forms. |
| open62541 (C) | The client has a configurable number of publish requests to keep outstanding. Reducing it is a one-line configuration change and is the correct response to this code. |
| Siemens S7-1500 | Embedded servers are typically stricter about queued requests than desktop-class servers. A client that is well behaved against a PC-based server may need its pipeline depth reduced for a PLC endpoint. |
What it looks like in the log
Publish rejected: BadTooManyPublishRequests; reducing outstanding publish count from 8 to 3
Server accepts at most 4 queued publish requests per session
Publish pipeline depth capped at 2 for endpoint opc.tcp://192.0.2.20:4840Confirm the fix
After capping, confirm the code stops appearing, that notification sequence numbers are contiguous, and that end-to-end latency from value change to consumer is still within what the publishing interval implies.
Stop it happening again
Configure an explicit outstanding Publish cap per session as part of your client template, keep notification handlers non-blocking, minimise the number of subscriptions, and record the cap that each server family tolerated so new deployments start correct.
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.