Should clarify batch operation's atomicity and consistency levels

[Mossaka]

According to the description of the batch interface

/// A batch operation does not guarantee atomicity, meaning that if the batch operation fails, some
/// of the keys may have been modified and some may not. 
/// 
/// This interface does has the same consistency guarantees as the `store` interface, meaning that
/// you should be able to "read your writes."

batch operations are said to be non-atomic, which implies partial failure and inconsistent reads, while the "read your writes" guarantee ensures consistent reads post-writing.

think about this example

1. Client A's batch operation starts.
2. Client A successfully writes V1_new to K1.
3. Before Client A writes to K2, Client B writes V2_b to K2
4. Client A attempts to write V2_new to K2 but fails

Resulting State:
K1: V1_new
K2: V2_b

Client A cannot read its own write to K2 because Client B's concurrent write interfered, and this contradicts the statement that "you should be able to 'read your writes'".

[thomastaylor312]

I'm not sure I follow your example. If Client A fails to write because another process wrote to it, then by reason of it failing, it wouldn't be able to read something that failed.