Programatically retrying AirVantage operations

Hey all,

I’ve been working with Google Cloud Functions and the AirVantage REST API to start syncing info from our backend to our hardware. We’ve been using /api/v1/operations/systems/settings to create an “apply settings” operation. I’ve also been passing a callback URL to watch the “state” change of the newly created operation.

Are we required to programatically retry these operations using a callback, or can AirVantage be configured to retry operations a certain number of times by default?



There is no automatic retry mechanism but you can manually retry an operation if it failed:

If the operation has not be delivered to the device, it will be delivered to the next device’s communication.


Thanks for the reply @rjacolin.

To make sure I understand correctly: if the operation is “pending”, it will be delivered on next communication, but if it fails, its up to me to retry.

My biggest concern with retrying would be causing some type of race condition. Suppose a user selects some settings and the settings get sent to the device over AirVantage. Later, they select some new settings, but the first operation failed and is therefore getting retried. From my perspective, it seems entirely possible for the “retry” of the old settings to overwrite the new (and correct) settings.

Is this a valid concern or does AirVantage have built in handling or suggested patterns for this case? One idea that comes to mind is querying operations when re-trying to avoid this scenario.


Hi Nick,

I’m not sure to understand how an automatic retry can solve your problem. The best way to resolve this race condition depends on your use case so a manual retry is better in this case. If you want to avoid the retry of an operation overwrite a new one, you have to make a check before retrying the operation that no operation has been applied before (as you said).

Note: for a single device, retry an operation or create a new one is the same. For a campaign (creating an operation applied on a set of devices), the retry will create a new operation with the failed tasks from the previous operation.

Hey @rjacolin,

These operations are generated automatically from our user application, so manually retrying is not possible.


By manual retry, I mean your user application must detect the first operation failed and retry it before pushing the new operation. You can define a dependency between the two operations as well so that the second operation will not be executed before the first one is successfully finished.