Sparkplug seq out of order — Sequence number gap in the Sparkplug stream

Every Sparkplug message carries a seq that increments 0-255 and wraps. A gap means a message was lost, and the host can no longer trust its state model for that node.

Start free MQTT / Sparkplug B → canonical

Diagnosis

When you hit this

QoS 0 publishing, where the broker is free to drop messages under load.
Network loss on a constrained link between edge node and broker.
Two edge nodes accidentally sharing a group and node id, so their sequences interleave.

Resolution

How to fix it

Publish at QoS 1
Sparkplug's state model assumes delivery. QoS 0 makes gaps routine rather than exceptional.
Rebirth on a detected gap
The correct response is to request a rebirth and rebuild state, not to interpolate across the gap.
Check for duplicate node ids
Interleaved sequences from two publishers look exactly like packet loss until you compare their payloads.

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.