A BLE reconnect callback is not readiness: model it as recovery or lose data quietly

The failure worth engineering against is the quiet one: the device reconnects, the interface reads connected, and measurements stop arriving ^[10]. In the post's framing the transport layer recovered while the data pipeline did not ^[10], and its remedy is to rediscover services and restore subscriptions after every reconnect rather than assume the previous GATT session survived ^[11].

Count the gates in its own readiness diagram. After BLE Connected there are five more steps before READY: service discovery, characteristic validation, notification subscription, application handshake, data synchronization ^[5][1]. The recovery path it draws after a reconnect has five steps as well ^[12][2]. Every transition is supposed to carry its own failure path ^[3], and none of those failures un-fires the connection callback. That is the whole case for reporting Transport Connected, Application Ready and Data Synchronized separately ^[6] rather than as one boolean the UI can lie with.

The data side outlives the link side. In the worked example the device emits M104, M105 and M106 while the connection is down ^[13], three records ^[3] that no amount of transport recovery brings back. Getting them requires the peripheral to have retained them and the app to recognise records it already holds, which is why the post asks for sequence numbers, timestamps or acknowledgements and an idempotent sync path ^[14][15]. That is a decision about record schema and firmware buffering, taken well before anyone writes the reconnect code.

The retry policy is where the advice has a price it does not quote. Attempts at 1, 2, 4 and 8 seconds, with a product-appropriate maximum on top ^[8], is 15 seconds of waiting across those four tries ^[4], all of it spent with the app blind and the device holding whatever it can, weighed against the battery drain, race conditions and stray BLE operations an immediate-retry loop produces ^[7]. Two of the six conditions the post enumerates, invalid credentials and an unpaired device, are not retry problems at all ^[9][6]. They need a human in a recovery flow, which means somebody has to write what that flow says and when it interrupts a measurement session.

This is one explainer that links onward to an agency's testing guide ^[16], and it carries no failure rates, no platform versions, and no field data on how often a reconnect completes without notifications resuming ^[5]. As evidence it is thin. As a checklist it is usable, and the part that can be checked cheaply is the test itself: a reconnection test that asserts on the connection callback is asserting on the component that did not break. The assertion has to be a notification arriving, and a gap backfilled, after the link returns, with the state machine and the BLE lifecycle held outside the screens that come and go ^[11][17].