BadSubscriptionIdInvalid (0x80280000) — The subscription id is not valid

The server has no subscription with that id — usually because it expired and was deleted while the client still held the handle.

Start free OPC UA → canonical

Diagnosis

When you hit this

The client stopped sending PublishRequests, so the subscription's keep-alive lapsed and the server deleted it.
Server restart. Subscription ids do not survive it.
Publishing was disabled long enough for the lifetime counter to run out.

Resolution

How to fix it

Keep publish requests in flight
The client must maintain a queue of outstanding PublishRequests. If the queue empties, the subscription dies even though the connection is healthy.
Recreate on this code, do not retry
The id is gone. Create a new subscription and re-add the monitored items rather than retrying with the stale id.
Raise the lifetime count
LifetimeCount should be at least three times MaxKeepAliveCount, which several SDK defaults do not satisfy.

Normalization

What Forge does about it

This is a transport failure, so there is nothing for Forge to normalize: the reading never arrives. What Forge does is refuse to let the gap look like good data. The read-time dropout check flags a field that fell to zero and recovered as a communication glitch rather than a real measurement, and the stuck-sensor check fires when a value repeats for 20 consecutive readings — which is what a cached or last-known value looks like after a link drops. Forge does not retry or reconnect for you; that is your client's or your gateway's job.