One way to insure that your CDB subscriber application hasn’t lost any CDB subscription notifications upon a reconnect is to keep track of the very last transaction ID from CDB. You can do that by using the cdb_get_txid() API call either inside or outside of a CDB session. In order to insure that you have indeed saved the latest txid in persistent storage, you will want to have a lowest priority subscription that is subscribed to the entire data model at the root with “/”. This will ensure that all notifications has been delivered and processed before you invoke the cdb_get_txid() call to save the most current transaction id in persistent storage.
cdb_get_replay_txids() allows you to find out the last transaction, txid[0], and the one before that, txid[1]. If your stored txid prior to the disconnect matches txid[1], you can invoke cdb_replay_subscriptions() to replay the lost CDB subscription notification. Please note that both of these APIs need to be invoked inside of a CDB session. In addition, the cdb_replay_subscriptions() call is blocking and needs to be invoked from a process (or thread) separate from the CDB subscriber. The replay functionality is only available if it has been enabled in confd.conf with /confdConfig/cdb/subscriptionReplay/enabled set to true.
If your stored txid is older than txid[1], you will need to either re-read everything from CDB or invoke cdb_trigger_subscriptions() to cause all of past CDB subscriptions to be triggered.
As an alternative, the cdb_mandatory_subscriber() call can be used while setting up the CDB subscriber in order to insure that all transactions don’t go through unless your CDB subscriber application is running.