Hi Tony Hillman,

I've been talk to Daniel Roberts about what is required here and is working on some code samples to help.
The main concern is regarding non-idempotent durable writes.
In particular - we current state in the documentation

 If the attempted durable write is not idempotent, the options are:

Verify the current state of the saved data; and re-attempt the durable write if appropriate.

Return an error to the user.

I thing we need code samples showing how to cope with am ambiguous result. And the gotchas associated with trying to use non-idempotent durable writes a perform tasks such as incrementing a value.

Daniel Roberts. Can you detail some of the challenges we discussed in this ticket? - thanks

As is the issue with an ambiguous response, finding out whether we've updated the value or not is in some way unknowable. In the case of a single client, we can use CAS values to determine whether or not the value has been modified by the ambiguous operation (but not if it may still be in the future - in the case of failed over / slow nodes etc.), but once multiple clients are allowed to edit the value, it becomes impossible(? suggestions welcome) to tell whether we modified the value or another client did (eg. if both clients GET -> x and SET x+10). Solutions for this issue fall into more complex application logic such as pessimistic locking, or breaking down the stored value such that it can be edited idempotently (eg instead of a single balance, keep an array of transaction history that is appended to). I'll write samples for both of these examples, and any others that are suggested.

Decision as per Daniel Owen is that the current account in the docs (https://docs.couchbase.com/server/6.5/learn/data/durability.html#handling-ambiguous-results) is sufficient. Further information to be provided by blogging.