I think we don't have many options here. Does the API or the model offer a method or field that could be used to determine if the operation has actually completed? If not, as a client, the only option we have is to try again, as you mention.
Another thing is to think about the scope of the tests. Do we need the tests to assert that the operation did actually complete int he provider? Or can we just assume that if the response contains the updated value, everything is OK and at some point it will be consistent? I mean, if we can minimize the chained operations that depend on the changes being applied int he provider, we could have more robust tests without the need of unnecessary eventual consistency logic. On 21 October 2017 at 22:12, Jim Spring <jmspr...@gmail.com> wrote: > Azure KeyVault APIs work in such a manner that they will return a valid > result, yet the operation may actually take time to complete. The only way > to verify is to perform an operation one expects to succeed and retry if it > fails (it seems). > > For instance: > > 1. Create KeyVault > 2. Update KeyVault to be enable soft delete > 3. Add Key > - Key should have a property of “Purgable+Recoverable”, sometimes it doesn’t > > The reason for the inconsistency in (3), the Vault is still updating. > Querying the vault indicates soft delete is enabled, yet the key will not > reflect that until the Vault actually updates. > > For testing purposes, I could do the following: > > 1. Create KeyVault with soft delete enabled > 2. Add Key > > Which will get me around the first example. However, there are other areas > where the problem still crops up, for instance deleting keys and testing > the recovery of them. Deleting a key and then listing the deleted keys can > take some time to actually show the key. > > Thoughts on how to approach this beyond the obvious approach of explicitly > retrying? > > Thanks > -jim
