pub fn code_can_read_data(
code_version: &Version,
data_version: &Version,
) -> boolExpand description
If persist gets some encoded ProtoState from the future (e.g. two versions of code are running simultaneously against the same shard), it might have a field that the current code doesn’t know about. This would be silently discarded at proto decode time: our Proto library can’t handle unknown fields, and old versions of code might not be able to respect the semantics of the new fields even if they did.
To detect the bad situation and disallow it, we tag every version of state written to consensus with the version of code it’s compatible with. Then at decode time, we’re able to compare the current version against any we receive and assert as necessary. The current version is typically the version of code used to write the state, but it may be lower when code is intentionally emulating an older version during eg. a graceful upgrade process.
We could do the same for blob data, but it shouldn’t be necessary. Any blob data we read is going to be because we fetched it using a pointer stored in some persist state. If we can handle the state, we can handle the blobs it references, too.