BadSubscriptionIdInvalid

BadLifecycle

What you actually see

Publish calls that were working start returning this code on every attempt, and no further data change notifications arrive, while a plain Read on the same session still succeeds.

Why it happens

• Subscription lifetime expired because the client stopped publishingA subscription is kept alive by outstanding Publish requests. LifetimeCount is expressed in publishing intervals, and when that many intervals pass with no Publish to send notifications on, the server deletes the subscription and tells you so the next time you reference it. A client blocked on a slow downstream sink is the usual reason it stopped publishing.
• Reconnect created a new session without transferring subscriptionsSubscriptions belong to a session. If your reconnect logic creates a fresh session instead of re-activating the old one, or calls TransferSubscriptions and ignores a failure, the old subscription ids are meaningless on the new session. The client keeps using the cached ids and gets this code for each of them.
• Client cached the id across a server restartSubscription ids are assigned by the server and are not stable across restarts. A collector that persists ids to disk, or a long-lived process that never invalidates its cache, will use a stale id after the server bounces.
• DeleteSubscriptions already succeededA second delete, or a delete racing with an in-flight Publish, returns this code. It is benign but it fills logs. Shutdown code that deletes subscriptions and then waits for the last Publish responses will see it every time.
• Server-side resource reclaimUnder pressure some servers reclaim subscriptions, especially ones with no outstanding Publish or a very long publishing interval. There is no notification when this happens - the only signal is this code on the next reference to the id.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Treat the code as a rebuild trigger, not a retry conditionRetrying Publish with the same id will never succeed. On this code, drop the local subscription object, call CreateSubscription and CreateMonitoredItems again, and re-apply your monitoring modes and filters. Every mature client SDK has a hook for this; use it rather than writing your own retry loop.
2. Log the revised publishing interval and lifetime you actually gotCreateSubscription returns revised values that can differ substantially from what you asked for. Compute your keep-alive expectation from the revised publishing interval multiplied by the revised LifetimeCount, not from your requested numbers, or your watchdog will be tuned to the wrong deadline.
3. Keep at least one Publish outstanding at all timesPublish is a long poll. If your code processes a notification synchronously before issuing the next Publish, a slow handler stalls the pipeline and eventually burns through the lifetime. Queue notifications to a worker and reissue Publish immediately.
4. Fix reconnect to re-activate the session or transfer explicitlyRe-activate the existing session on a new secure channel where the stack supports it, which preserves subscriptions. Where you must create a new session, call TransferSubscriptions and check every per-item result - a partial success means some subscriptions moved and others must be rebuilt.
5. Add a subscription watchdogFire an alarm when no notification and no keep-alive has arrived for a multiple of the publishing interval, and have the watchdog rebuild rather than just log. This catches the case where the server silently deleted the subscription and your Publish loop has already given up.

Where it shows up, by tool and stack

What it looks like in the log

Publish failed for subscription 4: BadSubscriptionIdInvalid
Subscription 4 no longer exists on the server; recreating with 128 monitored items
TransferSubscriptions returned BadSubscriptionIdInvalid for 2 of 3 subscriptions

Confirm the fix

After rebuilding, confirm the new subscription id appears in your logs alongside the revised publishing interval, and that keep-alive messages arrive on schedule with no further occurrences of the code over several lifetime periods.

Stop it happening again

Never persist or hardcode subscription ids, keep one or more Publish requests outstanding continuously, derive watchdog timeouts from the revised publishing interval and LifetimeCount, and make reconnect either re-activate the session or check every TransferSubscriptions result.

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.