Protocol implementation details are insufficiently abstracted over

[fhars]

The library expects that users provide some generic MQTT subscribe and unsubscribe functions, but doesn't really tell what to do with packets recieved in response to these subscriptions, which is a bit unfortunate as the application has to pass the data received using different events (OtaAgentEventReceivedJobDocument or OtaAgentEventReceivedFileBlock). So one has to rifle through the source of the library to find out which topics it may subscribe to and then dispatch in the application code. And this is quite error prone as you have to very specific about which data you pass to the library, if you for example pass everything that matches "$aws/things/+/jobs/#" as an OtaAgentEventReceivedJobDocument event, you invariably run into

1454 39489 [Cloud] [DEBUG][Cloud][39489] Packet on $aws/things/MwAcABNQUk5VODkg/jobs/AFR_OTA-fw-dev-20210526-124903/update/accepted{"timestamp":1622034320}
...
1474 39658 [OTA] [DEBUG][OTA][39658] Found valid event handler for state transition: State=[WaitingForFileBlock], Event=[ReceivedJobDocument]

which then aborts the current transfer, re-requests the next job and starts the transfer again, which then gets about as far as the attempt before. Also, the AppCallback is never called with OtaJobEventProcessed for these messages, so the buffers used for these messages are never freed (which can be seen as a saving grace in this case, as it prevents the code from downloading the first few blocks of the update in an endless loop until the included data volume on the SIM card is exhausted).

[pvyawaha]

Hello,

Thank you for reporting this , we are now actively looking into reproducing and fixing the issue and also looking into test cases and support for OTA on platforms with cellular connectivity.

[lightblu]

+1 and see #218 (comment) - this at least needs to be much better documented.

[n9wxu]

No further development will be performed on this library. See the readme.