Client should recreate Subscription if the Server is incorrectly reporting BadNoSubscription

[elpht]

Type of issue

• Bug
• Enhancement
• Compliance
• Question
• Help wanted

Current Behavior

I got a case in which the server starts responding with BadNoSubscription without the client trying to delete the session/subscription.
I could reproduce it with a unit test:

1. Instantiate and start OPC-UA server
2. Instantiate and connect OPC-UA client, configuring at least 1 monitored item
3. Trigger a change of that monitored item on the server and verify that it is received by the client
4. Delete all subscriptions from the server
5. Trigger further changes of the same monitored item

After the execution of step 4:

• No further data changes are received by the client
• The session is still alive
• The OPC-UA client isn't resubscribing
• The OPC-UA client doesn't report any event so that the application code can handle it (which, ideally, could be handled by the OPC-UA client)

Maybe that was caused by a buggy OPC-UA server or app code built on top of it, but this leaves the client app powerless against this situation. In our case, it left a customer plant standing still until the client app was restarted.

Is there any workaround to detect and handle it?

Expected Behavior

When the client receives BadNoSubscription from the service, but there is actually one or more subscriptions and the client isn't in the process of disconnecting the session, I expect that the client resend the subscription(s) and reports the data changes with the last values from the server.

Steps To Reproduce

I build a small repro -> repro.zip
That solution includes 2 integration tests:

• One that contains the repro, i.e. shows that no further data change is received if the server drops the subscription
• A second one that shows how the client behaves as expected, reconnecting and receiving further data changes, when the server drops the session.

Environment

- OS: Windows 11
- Environment: JetBrains Rider 2025.3.1
- Runtime: .NET 8.0
- Nuget Version: 1.5.378.65
- Component:
- Server:
- Client:

Anything else?

No response

[romanett]

@elpht would it be enough for your usecase to only recieve the PublishErrorEvent?

recreating the subscriptions automatically adds quite a bit of logic for this IMO quite rare case of a ,misbehaving server loosing a subscription but keeping the session?

[elpht]

At least, for now, that would give me a chance to detect such situation and react upon it. In the long run, though, it would be great that it gets handled by the client library.

[romanett]

#3502

[romanett]

Please open a PR with a more sophisticated solution if you need one