Adding new variants of the error in the middle will break the serialization and deserialization for the upgradable WASM executor. Because the new variants may have a different layout, and the error is included in the output type from the WASM executor(in the transaction statuses).
Because of that, we shouldn't remove any old variants and should add new variants at the end of the error enums.
To prevent any breaking changes, we need to add tests that ensure that behavior.
The alternative path is to not use enums as an output result of the executor and return a String, for example. In this case, the database will be not sensitive to the order of variants and we need this strange rule.
Adding new variants of the error in the middle will break the serialization and deserialization for the upgradable WASM executor. Because the new variants may have a different layout, and the error is included in the output type from the WASM executor(in the transaction statuses).
Because of that, we shouldn't remove any old variants and should add new variants at the end of the error enums.
To prevent any breaking changes, we need to add tests that ensure that behavior.
The alternative path is to not use enums as an output result of the executor and return a
String, for example. In this case, the database will be not sensitive to the order of variants and we need this strange rule.