`txn-list-append` workload fails to detect invalid return for read operations about maelstrom

[aphyr]

Only option 1 is valid there. You want precise equality *except* for read values, which should be null in the invoke. :-)

[aphyr]

Ah, yeah, this is somewhere we could do more rigorous checking. As far as Jepsen and Elle are concerned your histories were, in fact, correct: append-only histories are always legal, and your system insisted that the transactions it executed were append-only! This generally doesn't come up in Jepsen testing because we control the transaction generation, but in Maelstrom we're blindly trusting whatever the node happens to return, and that's clearly not correct. I'd welcome a patch to either Maelstrom or Elle which validates that completion transactions are compatible with their invocations!

[aquarhead]

Thanks for clarifying, I had a rough understanding of this history concept. I'm not entirely sure what should be considered as "compatible" though - does each µ-op must return in same order? or does it allow reordering but each µ-op need to present? or does it allow multiple µ-op to map to a single one in request? (e.g. multiple read response for a single read request)

For example for this input [[:append 224 6] [:r 226 nil]], which ones of the following should be considered as valid?

1. [[:append 224 6] [:r 226 [1]]] - exact order (can be checked by comparing array of function + key)
2. [[:r 226 [1]] [:append 224 6]] - reordered but all µ-ops exist (check with set of function + key)
3. [[:append 224 6] [:r 226 [1]] [:r 226 [1 2]]] - multiple read responses (check function + key count?)

(I haven't finished the entire Datomic chapter so might be a dumb question)

[aquarhead]

BTW I opened a PR ^ for this in case you missed it :D