GoodSubscriptionTransferred

GoodReconnect

What you actually see

After a network interruption or a channel renewal, the client logs this code once per transferred subscription and data resumes without any monitored items being recreated.

Why it happens

• A reconnect that transferred subscriptions instead of rebuilding themA secure channel is not a session, and a session can be re-bound to a new channel. When a client re-establishes and calls TransferSubscriptions, the server moves each subscription to the new session and reports this. This is the designed path and it is much cheaper than recreating thousands of monitored items.
• Redundant client taking overIn a client redundancy arrangement the standby can take over a subscription from the failed primary. The transfer is the mechanism, and this code is how each party learns it happened. Nothing is wrong; ownership moved.
• Client library recovering from a channel-level faultCodes such as an expired channel security token, a closed channel or a transport reset trigger the stack's reconnect handler. It reopens the channel, re-activates or recreates the session, transfers subscriptions and reports this per subscription. Most of that happens without application code being involved.
• Durable subscription surviving a longer outageDurable subscriptions are designed to persist across reconnects with a longer retained queue, so a transfer after a substantial gap is possible and expected. Handling the transfer and then republishing the retained notifications is what recovers the data.
• Deliberate migration of a subscription by an operator or toolA management tool or a client that intentionally moves work between sessions produces the same result. If you see this without a corresponding network event, look for something in your own architecture that transfers on purpose.

How to fix it

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

1. Accept it and do not rebuildLog it at information level and continue. Client code that treats any non-Good-simple status as a fault and tears down the subscription throws away the benefit of the transfer and produces a value storm from recreating every monitored item.
2. Republish the gapNotifications that the server sent while the old session was unreachable are held for retransmission. Use Republish with the sequence numbers you are missing to recover them. Track sequence numbers continuously so you know exactly what to ask for rather than guessing.
3. Re-apply anything that does not transfer with the subscriptionThe subscription and its monitored items move, but check your assumptions about publishing mode and any client-side state keyed to the old session. Confirm PublishingEnabled is set as you expect and that the item count on the new session matches what you configured.
4. Check every per-subscription result, not just the firstTransferSubscriptions returns a result per subscription. A partial success means some transferred and some must be rebuilt. Code that checks only the overall service status will silently lose the subscriptions that did not move.
5. Prefer re-activating the session over creating a new oneWhere the stack supports re-binding an existing session to a new secure channel, subscriptions stay put and no transfer is needed at all. Reserve TransferSubscriptions for the case where a genuinely new session is unavoidable.
6. Make the transfer visible in your operational metricsCount transfers per endpoint. A steady trickle of them points at an unstable network path or an aggressive channel lifetime, which is worth fixing even though each individual recovery worked.

Where it shows up, by tool and stack

What it looks like in the log

TransferSubscriptions: subscription 3 GoodSubscriptionTransferred to session ns=1;i=8842
Reconnected after 6 s; 4 subscriptions transferred, 0 recreated
Republish requested for sequence numbers 8891 to 8896 after transfer

Confirm the fix

Confirm notifications resume on the new session with contiguous sequence numbers after any Republish, and confirm the monitored item count on the transferred subscription matches your configuration rather than assuming the transfer was complete.

Stop it happening again

Use the stack's managed reconnect rather than hand-rolled recovery, track notification sequence numbers so gaps can be republished, check per-subscription transfer results, and count transfers per endpoint as a link-stability metric.

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.