Given the following example (pseudocode, we should write an actual test)

1:  Transaction txn = MakeReadWriteTransaction();
2:  auto result1 = client_->ExecuteDml(txn, "INSERT that will fail (duplicate row)");
3:  auto result2 = client_->ExecuteDml(txn, "INSERT that will succeed");
4:  auto commit_result = client_->Commit(txn, {});

In our client library, although the first ExecuteDml fails, the second succeeds, as does the Commit.
This behavior may be seen as violating the atomicity guarantee - users may expect that the failure of the first ExecuteDml means that the transaction cannot successfully Commit. From http://goto.google.com/spanner-txns#atomicity-consistency-durability

In addition to the Isolation property, Spanner provides Atomicity (all writes must succeed in order for the transaction to commit; if one or more writes within the transaction fail, the entire transaction fails), [...]

The reason our client library behaves this way is because we defer Transaction begin until the first operation that uses the transaction as an optimization. If the first operation on a Transaction is a write (DML) that fails, the Spanner backend does not actually begin the transaction or return one in the response, the C++ Transaction object remains in its initial state; assuming all subsequent DML operations succeed, the Commit will also succeed.