An OPC UA server returned a ServiceFault with BadNoSubscription 0x80790000 after approximately 10 minutes of continued PublishRequest and PublishResponse traffic. The trace also contained one RepublishRequest and RepublishResponse exchange approximately 10 minutes before the fault. The supported diagnosis is that the subscription expired; the trace sequence alone does not establish that Republish caused the expiration.
Interpret the Fault in Session Context
PublishRequests are queued by the client and shared by all subscriptions in the same session. A server dequeues a queued request when it needs to return a PublishResponse. Therefore, a one-to-one client/server connection does not by itself prove that only one subscription uses the session's PublishRequest queue.
| Observed evidence | Engineering conclusion |
|---|---|
BadNoSubscription 0x80790000 returned as a ServiceFault |
The server no longer has a subscription available for the PublishRequest. |
| Publish traffic continued for approximately 10 minutes | Packet presence alone does not prove that the affected subscription received sufficient PublishRequests throughout its lifetime. |
| One Republish exchange occurred earlier | The timing is relevant for trace correlation, but it does not prove that Republish triggered expiration. |
Check the Subscription Lifetime
The primary failure hypothesis is subscription timeout. Record the subscription settings and the values returned by the server when the subscription is created, especially CurrentLifetime. Also capture the publishing interval and keepalive settings. Without those values, the trace cannot determine whether the approximately 10-minute interval matches the negotiated subscription lifetime.
Audit the PublishRequest Queue
A subscription can time out when the client does not maintain PublishRequests or when queued requests are consumed by higher-priority subscriptions. Even if the connection is one-to-one, enumerate every subscription in the session and check whether they share the same request queue.
- Confirm that subscription creation completed successfully and record the server-returned
CurrentLifetime. - Record the publishing interval and keepalive settings for the affected subscription.
- Count outstanding PublishRequests over the interval leading to the fault; verify that the client normally queues more than one rather than waiting for each response before sending the next request.
- Enumerate all subscriptions in the session and check whether another subscription, including one with higher priority, consumes the queued requests.
Correlate Republish Without Assuming Causation
Align the subscription-creation time, the Republish exchange, PublishRequest queue depth, PublishResponses, and the final ServiceFault on one timeline. If the fault occurs when the negotiated lifetime expires and the request queue was absent or unavailable to the affected subscription, the timeout diagnosis is supported. If requests remained queued and no competing subscription consumed them, collect the creation response and complete trace for library or server analysis rather than attributing the failure to the single Republish exchange.
FAQ
What does BadNoSubscription 0x80790000 on PublishRequest indicate?
It indicates that the server has no subscription available for that PublishRequest. In this case, subscription expiration is the primary diagnosis to test.
Can a RepublishRequest cause BadNoSubscription 10 minutes later?
The observed timing does not prove causation. Compare the server-returned CurrentLifetime with the trace timeline and verify PublishRequest availability before linking the two events.
Which OPC UA subscription values should I capture?
Capture CurrentLifetime, the publishing interval, keepalive settings, all subscriptions in the session, and the number of outstanding PublishRequests leading up to the ServiceFault.
