Best practices for handling potential race conditions for vcmp config sync

I am aware there is a mix of resources on vCMP devices that will sync between an active/standby configuration between clustered vCMPs and some will not, for example static vs floating self ip addresses. If some of these resources depend on each other then when you make an api call is the sync completed by the time you get a response or does the sync happen at an arbitrary and unpredictable timing. I am thinking for situation where you may wish to be sure that all devices are in sync before continuing to a subsequent API operation.

An example of this might be deleting a floating self IP address on a vlan before a static, the floating delete can happen on the active device and then sync to the others, the static must happen on all devices, however is it possible a delete on a standby device might be attempted before all devices sync if there is a sufficient delay in the sync happening? If this kind of race condition is possible then how should it be managed programmatically via the api to ensure race conditions do not happen.

Also if you mutate an object that will sync to all devices on a standby device instead of an active device then how is that managed? particularly if you modify the same object on more than one device simultaneously? I am thinking of a situation where the device that is active changes as you are modifying it for example. Finally, is there detailed documentation on how config sync operates?