CommitInfo values written to the DB are non-deterministic -- does it matter?

[08d2]

The rootmulti.Store's Commit method sets rs.lastCommitInfo to the result of calling the commitStores function, and then later passes that value to the flushMetadata function.

The flushMetadata function calls the setCommitInfo function which sets a key/value pair on the provided batch, with the key being based on a height, and the value being the result of the CommitInfo's Marshal method. That Marshal method calls MarshalToSizedBuffer, which encodes each of the CommitInfo's StoreInfo values in the (reverse) order as they are defined in the slice.

That slice is built by the commitStores function, which ranges over a map of StoreKeys to CommitKVStore interfaces, and appends the result of some computation on those values to the slice, one by one. Ranging over a map is defined to be random. That means the value of these CommitInfo keys — persisted to the DB, as part of a batch, with each call to the rootmulti.Store Commit method — are non-deterministic.

I stumbled over this curiosity while trying to diagnose AppHash failures on replay. But I'm not actually sure if this non-determinism matters. Does it?

[tac0turtle]

this is a good place to start for this #6370

[yihuang]

I guess not, otherwise we should notice long time ago 😄
I guess the commit info is not committed into the app hash?

[alexanderbez]

No, these objects written to disk as part of the commit execution are not used as part of the app's merkle-ized tree. Thus, the map iteration is not important. However, I'd still argue that we should make it deterministic for brevity and testing's sake.

[08d2]

Thanks for the fast response!