Adjust the chain sync and block fetch codec formats slightly
Put the header and block types into a CBOR bytestring wrapper. This has a number of advantages:
- It makes it straightforward to pass on the data without decoding it, or delay decodoing.
- It allows a single CDDL spec, for many instantiations to different header and block types.
- It allows decoders access to the raw input bytes, without any further wrapper. This is needed for decoding the cardano-ledger headers and blocks where we need to annotate with the original bytes for verification purposes.
- This has to be done anyway for cardano-ledger, which is a change in CBOR schema. This just centralises that so the schema can be specified in one place.
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
putBlock, because it just called
hPut once. We could just look in
Errors to see whether the first call to
hPut would result in a
With partial writes the story changes, because one call to
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
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.