BadRequestInterrupted
BadNetwork drop
BadRequestInterrupted means your request did not complete because the transport was interrupted while it was in flight. The server may or may not have executed it. Reconnect the channel, then re-issue idempotent operations freely and reconcile writes and method calls by reading back before retrying them.
What you actually see
Several in-flight requests fail together at the exact moment a reconnect starts, with no server-side fault reason attached to any of them.
Why it happens
- The socket died while the request was in flightA link failure, a switch failover, a wireless roam or a VPN renegotiation cuts the connection between send and response. The stack reports the interruption rather than a timeout because it already knows the transport is gone, which is useful information: the request budget was not exhausted, the path was.
- The client abandoned the request during its own reconnectReconnect helpers cancel outstanding requests when they replace a channel or a session. Application code that treats every fault as a server error logs this as a server problem when it was the client's own recovery path doing exactly what it should.
- The secure channel was replaced under a queued requestRequests queued behind a channel renewal or replacement cannot be sent with the old key material. Discarding them here is correct; resending them on the new channel with stale signatures produces BadSecureChannelTokenUnknown instead.
- Client shutdown or task cancellationDisposing the client, cancelling the task group, or leaving the async context while requests are outstanding interrupts them. This is expected during an orderly stop and should not raise an alarm.
- A congested or lossy linkOn cellular, satellite or saturated plant wireless, send buffers fill and connections stall. Repeated occurrences with no matching infrastructure event point at link quality rather than at configuration.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Classify the operation before retrying anythingRead and Browse are safe to repeat. Write, Call, and anything that increments a counter or starts a job are not, because the server may have executed them before the interruption. Read the affected value back and reconcile before re-issuing.
- Reconnect through the layers in orderNew socket, new secure channel, re-bind or recreate the session, then TransferSubscriptions handling GoodSubscriptionTransferred. Do not attempt to resend on the dead channel.
- Separate your own cancellation from a real network faultSet a shutting-down or reconnecting flag and suppress error-level logging while it is set. A large share of this code in monitoring systems is self-inflicted cancellation, not network loss.
- Correlate timestamps with infrastructure eventsLine the faults up against switch logs, VPN events, container restarts and the server log. A match means there is nothing to fix in OPC UA; no match across many occurrences means you have a measurable link problem.
- Add bounded backoff with jitterAn immediate tight retry after an interruption converts one blip into a fleet-wide connect storm, producing BadServerTooBusy and orphaned sessions. Bound the delay and randomise it per client.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | SessionReconnectHandler cancels outstanding requests while re-establishing the channel, so this code appears during normal recovery. Distinguish it from a genuine fault by whether a reconnect was already in progress. |
| node-opcua | Pending requests reject when connection_lost fires. Guard callbacks with a reconnecting flag rather than treating each rejection as an independent failure worth alarming on. |
| asyncua (Python) | In-flight coroutines raise when the transport closes. Wrap writes and method calls in code that reads the value back on this error instead of retrying blindly. |
| open62541 (C) | The state callback reports the connection layer separately from the channel and session layers, which tells you at a glance that the interruption was below the channel. |
| Wireshark OPC UA dissector | Shows whether the last thing on the wire was a partial chunk, a graceful CLO, or a bare TCP RST - three different stories behind the same client-side error. |
What it looks like in the log
BadRequestInterrupted: the request could not be sent because of a network interruption
Cancelling 3 outstanding requests on channel 12 before reconnect
Write to ns=3;s=Machine1.SetPoint interrupted; value not confirmed, reading backConfirm the fix
Pull a cable deliberately and confirm you get one burst of this code, a clean reconnect, a successful TransferSubscriptions, and no duplicated writes or method calls afterwards.
Stop it happening again
Make every client operation either explicitly idempotent or explicitly reconciled, mark planned disconnects as planned, and track the interruption rate as a network health metric rather than an application error.
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.