Clearly distinguish failed writes from indeterminate writes.

[mlucy]

This is the current state of error reporting for writes in RethinkDB:

• If an error occurs that prevents the write from succeeding on a specific document, we set the errors field of the result document and continue executing other writes.
• If an error occurs that prevents the write from succeeding at all (e.g. we can't contact the primary or we get a type error before the write even executes), we throw a ReQL error.
• If an error occurs that prevents us from knowing whether or not the write succeeded, or if the write succeeded on the master but wasn't acked by a majority of replicas, we throw a ReQL error and somewhere in the text of the error we describe the problem.

It's possible by regex matching on error messages to determine from the output of a ReQL query whether or not a write is known to have failed, but it's tricky and easy to miss a case. This is making integrating with the jepsen tests hard, and is probably inconvenient for users as well.

I think we should find a way to make clear in the return value whether or not the write is known to have failed or is in an indeterminate state. Here are a few options:

1. We use the object/error distinction.

Basically the rule would be "If you get back a result object with errors: n where n != 0, one or more of your writes is known to have failed. If you get back a ReQL error, your write is in an indeterminate state."

2. We introduce more error types.

We currently just have compilation, runtime, and driver errors. We've been meaning to introduce more error types for a while. We could have WriteFailedError and WriteIndeterminateError which subclass from WriteError.

3. We add meta information on the error to the response notes.

We'd have a note WriteFailed or WriteIndeterminate. This has the advantage of not breaking existing drivers, but it also makes it easy for driver writers to blithely ignore the existence of this distinction and thus not expose it to users.

---

@coffeemug, @danielmewes, @timmaxw -- thoughts?

[coffeemug]

Could you grab me for a moment today to chat about this in person? There are a few subtleties that would be easier to discuss verbally.

[mlucy]

@coffeemug and I talked about this in person (I talked about it a bit with @timmaxw on slack as well), we decided to go with a simple error hierarchy for now.

[mlucy]

This is in next.