Persistence.db stores all the messages the device sends to the broker.
After using sendData, a property is stored on the persistent_entries table;
If a message fails to be sent, it becomes a cachemessage (class) and is stored on the cachemessages table;
When the SDK starts running it will load the stored cachemessages and the sendProperties and try to send it to the broker.
The customer can access its device, stop the SDK, upgrade an interface from version 1.0 to version 2.0. This upgrade from major version, means the customer changed an existent endpoint (i.e.: deleted or changed its type or another thing) and start the SDK again.
This case means the endpoint stored on persistent_entries or cachemessages table is not valid for that interface anymore.
Even so, the SDK tries to send all the cachemessages and persistent_entries without validating its mapping (as it was validated when the SDK was running and with the interface on v1.0). This way, the SDK will send an old message (from 1.0) for the interface he upgraded (now 2.0) and so the SDK will be disconnected from Cloud on loop, until you remove the entry from the persistent_entries and cachemessages...
Environment:
Will happen on all versions.
Steps:
(Case for properties interface but can be replicated on datastream if you force the messages to fail...)
Get an interface from any version.
Delete and endpoint from this interface and increase the major version.
Restart the SDK.
See the SDK will be on loop trying to send the endpoint you removed as it's stored on the persistent_entries from the persistence.db
Current Results:
SDK will be on loop trying to send the endpoint you removed as it's stored on the persistent_entries from the persistence.db
Expected Results (Suggestions):
SDK needs to validate the mapping from cachemessages on initImpl of astartetransportcache.cpp and so not try to send messages that does not match the mapping.
SDK needs to validate the mapping from persistent_entries and not try to send properties that does not match the mapping.
Description:
Persistence.db stores all the messages the device sends to the broker. After using sendData, a property is stored on the persistent_entries table; If a message fails to be sent, it becomes a cachemessage (class) and is stored on the cachemessages table; When the SDK starts running it will load the stored cachemessages and the sendProperties and try to send it to the broker.
The customer can access its device, stop the SDK, upgrade an interface from version 1.0 to version 2.0. This upgrade from major version, means the customer changed an existent endpoint (i.e.: deleted or changed its type or another thing) and start the SDK again. This case means the endpoint stored on persistent_entries or cachemessages table is not valid for that interface anymore. Even so, the SDK tries to send all the cachemessages and persistent_entries without validating its mapping (as it was validated when the SDK was running and with the interface on v1.0). This way, the SDK will send an old message (from 1.0) for the interface he upgraded (now 2.0) and so the SDK will be disconnected from Cloud on loop, until you remove the entry from the persistent_entries and cachemessages...
Environment:
Will happen on all versions.
Steps:
(Case for properties interface but can be replicated on datastream if you force the messages to fail...)
Current Results:
SDK will be on loop trying to send the endpoint you removed as it's stored on the persistent_entries from the persistence.db
Expected Results (Suggestions):
SDK needs to validate the mapping from cachemessages on initImpl of astartetransportcache.cpp and so not try to send messages that does not match the mapping. SDK needs to validate the mapping from persistent_entries and not try to send properties that does not match the mapping.
Additional Information:
None.