BadContinuationPointInvalid
BadLarge browse
BadContinuationPointInvalid means the continuation point you sent is no longer valid. Servers release them on a timeout, when the session ends, or when their pool is needed elsewhere. Continue a paged browse promptly, hold no more than you need, and restart the traversal from the node rather than retrying the point.
What you actually see
A large browse or history query works for the first few pages and then fails partway through, more often on a loaded server or when the client paused between pages.
Why it happens
- Continuation point timed outServers hold continuation points only for a limited time, since each one is state associated with a partially completed operation. A client that pages slowly - because it processes each page synchronously, or waits on a downstream system - can return after the point has been released.
- Server released it under pressureContinuation points are a capped resource. A server needing capacity for other clients may release older points. Your traversal then fails through no fault of its own, which is why paged browsing needs a restart path rather than only a retry.
- Session or channel changed underneath the traversalContinuation points belong to the session. A reconnect, even a successful one that transferred subscriptions, invalidates them. Code that resumes a browse after a reconnect using a saved point will always fail.
- Point reused after it was already consumed or releasedA continuation point is single-use: each BrowseNext returns either a new point or none. Sending the same point twice, or sending one you already released with releaseContinuationPoints, is invalid. Retry logic that resends the last request on any error produces this.
- Point mixed up between concurrent traversalsA client running several paged browses in parallel and holding points in a shared structure can send the wrong point for the wrong node. The code is the same as for an expired point, so the bug hides behind a plausible explanation.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Page promptly and do not block between pagesIssue the next BrowseNext immediately and process the results afterwards, rather than processing each page before continuing. Buffer the pages and hand them to a worker. This alone removes most occurrences on a busy server.
- Restart the traversal on this code, do not retry the pointThe point is gone. Restart from the node you were browsing, ideally with a smaller MaxReferencesPerNode so the traversal completes in fewer, faster pages. Keep enough state to know where you were so you can resume at node level.
- Release points you abandonWhen you stop a traversal early, call BrowseNext with releaseContinuationPoints set so the server frees the state. Leaking points exhausts the pool and causes failures for you and for other clients.
- Reduce reliance on pagingFilter the browse by ReferenceTypeId, IncludeSubtypes, NodeClassMask and ResultMask so fewer references come back. Where you know the model, use TranslateBrowsePathsToNodeIds instead of traversing. Fewer pages means fewer opportunities to lose a point.
- Key each point to its traversalStore the continuation point alongside the node and traversal it belongs to, and pass it only for that traversal. In concurrent code, make the point part of the per-traversal state rather than of a shared map.
- Export the address space once for large modelsWhere you repeatedly walk a large address space, export it to a NodeSet once and work offline. That removes paged browsing from the critical path entirely and is the standard approach for very large models.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | The managed browse helpers handle BrowseNext and release for you. Hand-written traversal must track the point per node and must release on abort; the reference server's continuation point pool is finite like any other. |
| asyncua (Python) | The high-level get_children handles paging internally. Custom traversal code must loop on the continuation point and release abandoned ones, and should not await slow work between pages. |
| node-opcua | session.browse and browseNext expose the continuation point directly. Build the paging loop as a shared helper with a release path rather than inline at each call site. |
| open62541 (C) | The browse response carries the continuation point as a ByteString you must pass back; both client and server cap how many exist. Free the client-side copy and release the server-side point when you abort. |
| UaExpert | It pages transparently while browsing large address spaces, so if UaExpert completes a browse your client cannot, the paging loop in your client is the place to look. |
| OPC Publisher | It offers streaming and fast browse features aimed at very large address spaces, which reduce how much continuation-point paging your own code has to do. |
What it looks like in the log
BrowseNext failed: BadContinuationPointInvalid after 4 pages
Continuation point for ns=4;i=5001 released by server after 30 s idle
Restarting browse of ns=4;i=5001 with maxReferencesPerNode 500Confirm the fix
Confirm the traversal completes with a final page carrying no continuation point, and confirm the node count you collected matches an independent count from a NodeSet export or from the same browse in a known-good tool.
Stop it happening again
Page without blocking, keep continuation points as per-traversal state, always release abandoned points, filter browses so fewer pages are needed, and export very large address spaces once rather than traversing them repeatedly.
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.