Disable partial writes for the VolatileDB q-s-m tests
The model for the VolatileDB used in the q-s-m tests predicts the outcome of
each operation based on the Errors that will be simulated. This worked out
okay for putBlock, because it just called hPut once. We could just look in
the Errors to see whether the first call to hPut would result in a
simulated error.
With partial writes the story changes, because one call to hPut now
potentially results in multiple calls to hPutSome. If we simulate a partial
read for the first call to hPutSome, a second call might be needed to read
the remaining bytes. If that is partial too, another call may be needed, and
so on. It is hard to predict how many calls will be needed, because we would
have to know how many bytes to write, and how many bytes have been written by
each partial write.
The partial writes alone are not really a problem, it is the combination with
a simulated error that is a problem. If we simulate an error for the nth
call to hPutSome where n > 1, we don’t know whether it will actually be
thrown or not, because we don’t know how many calls to hPutSome will be
needed. So in the model we can’t predict whether the operation will succeed or
not and the model will get out of sync with the real implementation.
For this reason, we just disable partial writes for the VolatileDB q-s-m
tests (for now).
We already know that hPut (and its variants) deal with it correctly, since
it works fine in the ImmutableDB q-s-m tests that do simulate partial writes.
Eventually, we want to stop predicting precisely whether an operation should
fail based on the simulated errors in the VolatileDB, because it is very
brittle. When that is done, we can enable partial writes here again.
