Accepting MQTT recovery in ThinkLink: subscriptions, gaps and duplicates

Map source to consumer

List Source Broker, subscription topic, transformation, Target Broker and final consumer. AS provides raw uplink messages while ThinkLink sources provide processed messages, so counts from different layers are not directly comparable. Specify target topics, fields and storage ownership. Use a test device or dedicated topic and assign traceable business identifiers. Equal counts do not prove absence of loss or duplication, and messages from several devices in the same second are not necessarily one event.

Confirm connection and subscription

RUNNING describes connection, not confirmed subscription or consumer processing. Current documentation distinguishes subscription registration from SUBACK; registration while a source is offline waits for recovery. Check rule enablement, actual topic and subscription confirmation, then send a known sample. A healthy target connection does not prove the transformation returned a message. Inspect a minimal authorized sample before and after transformation without exporting unrelated organizational data for debugging.

State the offline contract

The documentation adds no buffering or replay guarantee when the target is unavailable. Receiving new messages after recovery does not fill the outage. Continuous-history requirements need a queryable source, compensation and deduplication design, with interval and field checks. A fixed client_id alone guarantees neither persistent-session restoration nor business reliability; unintended duplicates can displace connections on the same Broker. Changing the ID reconnects, so record and schedule the test. Automatic reconnection is not a promise of lossless data.

Test three interruption scenarios

Establish a baseline, then independently interrupt the source, target and consumer. After each recovery, compare connection, subscription, target messages and stored business records, listing missing and duplicate identifiers. Avoiding duplicate local listeners does not eliminate MQTT redelivery or sender retries. Define deduplication from device identity and suitable message identifiers or sequences; timestamp-only filtering can discard legitimate same-second data. State which layers recovered, which historical gaps remain and which layers were not observable.

1. Establish traceable baseline samples.
2. Interrupt source, target and consumer separately.
3. Check SUBACK, target messages and stored records.
4. Assign gap, duplicate and compensation handling.

Give the consumer a recovery runbook

Deliver topics, field contracts, owners, test identifiers, reconnect procedure, gaps and duplicate-handling policy. Server and shared attributes may be allowlisted subsets requiring field merges. Status events lack ordinary telemetry structure and can be discarded by telemetry-only transformations. Recheck filters and target handling when adding message types. Acceptance ends at the business consumer, not the connection indicator. Historical replay, event ordering and reliable audit are separate design and verification requirements.