# \[FB15034\] OPC-UA - Bad\_ContinuationPointInvalid **URL:** \ **Category:** Ignition Early Access\ **Created:** [September 18, 2019, 12:16pm UTC](https://forum.inductiveautomation.com/t/fb15034-opc-ua-bad-continuationpointinvalid/28341 "2019-09-18T12:16:29Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![chi](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@chi](https://forum.inductiveautomation.com/u/chi)\ **Post date:** [September 18, 2019, 12:16pm UTC](https://forum.inductiveautomation.com/t/fb15034-opc-ua-bad-continuationpointinvalid/28341/1 "2019-09-18T12:16:30Z")
I’m trying to connect Ignition 8.0.4RC1 to the TANI OPC-UA server and get an exception. The server runs on the same machine as the Ignition 8 gateway. A remote 7.9 gateway is connected to the same server and works without problems. Any ideas what might be causing this? ```auto UaException: status=Bad_ContinuationPointInvalid, message=The continuation point provide is longer valid. at com.inductiveautomation.ignition.gateway.opcua.client.connection.DataTypeTree$Companion.browse(DataTypeTree.kt:266) at com.inductiveautomation.ignition.gateway.opcua.client.connection.DataTypeTree$Companion$browse$1.invokeSuspend(DataTypeTree.kt) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:241) at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:594) at kotlinx.coroutines.scheduling.CoroutineScheduler.access$runSafely(CoroutineScheduler.kt:60) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:740) ``` ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 18, 2019, 12:55pm UTC](https://forum.inductiveautomation.com/t/fb15034-opc-ua-bad-continuationpointinvalid/28341/2 "2019-09-18T12:55:42Z")
Can you get a Wireshark capture? If I had to guess I’d say maybe they are returning an empty continuation point (rather than null) and we’re calling BrowseNext with that anyway. ---
**Author:** ![chi](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@chi](https://forum.inductiveautomation.com/u/chi)\ **Post date:** [September 19, 2019, 7:00am UTC](https://forum.inductiveautomation.com/t/fb15034-opc-ua-bad-continuationpointinvalid/28341/3 "2019-09-19T07:00:40Z")
Hello Kevin, here is the Wireshark capture. The connection to this server worked in 7.9 and 8.0.3. The problem emerged with version 8.0.4rc, the capture is from 8.0.4. [opcua.zip](https://us1.discourse-cdn.com/inductiveautomation/original/2X/3/3bb202ef7c97c4fb83b3b624f83f3c1af9ab83ef.zip) (52.6 KB) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 19, 2019, 3:28pm UTC](https://forum.inductiveautomation.com/t/fb15034-opc-ua-bad-continuationpointinvalid/28341/4 "2019-09-19T15:28:33Z")
This looks like a bug in the server to me. It’s returning Bad\_ContinuationPointInvalid in the BrowseResult of a response to a regular BrowseRequest, which doesn’t even make any sense. I’ll have to look into what might have changed between 8.0.3 and 8.0.4-rc though. ---
**Author:** ![chi](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@chi](https://forum.inductiveautomation.com/u/chi)\ **Post date:** [September 19, 2019, 6:01pm UTC](https://forum.inductiveautomation.com/t/fb15034-opc-ua-bad-continuationpointinvalid/28341/5 "2019-09-19T18:01:38Z")
Ok, thank you. Let me try to restart the server tomorrow. Maybe there is a bug that only shows on new connections and don’t affect existing ones. ---
**Author:** ![chi](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@chi](https://forum.inductiveautomation.com/u/chi)\ **Post date:** [September 20, 2019, 11:14am UTC](https://forum.inductiveautomation.com/t/fb15034-opc-ua-bad-continuationpointinvalid/28341/6 "2019-09-20T11:14:06Z")
A restart had no effect. The problem is reproduceable on two seperate systems. I added another capture from a working Ignition 7.9 connection. When you look a the BrowseResponse with Request Id 173, the servers answer is the same. It looks like the client ignored this exception in versions prior 8.0.3rc. [opcua\_ok\_7\_9.zip](https://us1.discourse-cdn.com/inductiveautomation/original/2X/0/070b0133ace38bd2cdad0eb998ecc80a22a3032f.zip) (23.9 KB) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 20, 2019, 11:38am UTC](https://forum.inductiveautomation.com/t/fb15034-opc-ua-bad-continuationpointinvalid/28341/7 "2019-09-20T11:38:41Z")
Yes, it looks like as part of a change related to browsing datatypes the StatusCode of the BrowseResult started being checked, where previously it was ignored. I can probably revert to the more lenient behavior in an upcoming 8.0.5 nightly. Can you report this to the server vendor as well? This is definitely a bug in the server. ---
**Author:** ![chi](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@chi](https://forum.inductiveautomation.com/u/chi)\ **Post date:** [September 20, 2019, 12:08pm UTC](https://forum.inductiveautomation.com/t/fb15034-opc-ua-bad-continuationpointinvalid/28341/8 "2019-09-20T12:08:23Z")
> [@Kevin.Herron](#): > > Can you report this to the server vendor as well? This is definitely a bug in the server. Yes, i already sent them the capture. ---
**Author:** ![awalker](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/awalker/32/6874_2.png) [@awalker](https://forum.inductiveautomation.com/u/awalker)\ **Post date:** [September 24, 2019, 3:53pm UTC](https://forum.inductiveautomation.com/t/fb15034-opc-ua-bad-continuationpointinvalid/28341/9 "2019-09-24T15:53:09Z")
This issue was fixed in the 8.0.5 nightly build that was uploaded today (9/24). ---
**Author:** ![chi](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@chi](https://forum.inductiveautomation.com/u/chi)\ **Post date:** [September 25, 2019, 12:18pm UTC](https://forum.inductiveautomation.com/t/fb15034-opc-ua-bad-continuationpointinvalid/28341/10 "2019-09-25T12:18:15Z")
> [@Kevin.Herron](#): > > Can you report this to the server vendor as well? This is definitely a bug in the server. This has meanwhile been fixed by the server vendor. It looks like browsing datatypes is not a commonly used feature. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 25, 2019, 3:08pm UTC](https://forum.inductiveautomation.com/t/fb15034-opc-ua-bad-continuationpointinvalid/28341/11 "2019-09-25T15:08:06Z")
Ignition 7.9.12+ and 8.0.0+ will browse all the DataTypes to construct a tree, which it then uses to support aliased datatypes. It’s become common in the servers embedded on PLCs to use alias datatypes, i.e. instead of using an OPC UA Int16 they make an alias type to INT or whatever the native equivalent is. Without building this tree it’s not possible for the Ignition client to resolve these aliases into their actual underlying type. Older versions of Ignition could read tags with aliased datatypes but not write to them. They would also not get the correct tag type set when you dragged them into Ignition.