MystenLabs
Enums: VM errors on hitting upper limit of allowed number of fields/depth
We have quite a complex enum/struct setup with nested enums and structs and are apparently hitting the upper limit set on the number of fields.
Publishing runs through successfully but using it leads to different kinds of issues. If the enum itself has too many fields (including nested structs/enums), we get the following error when trying to create an instance of this enum: https://testnet.suivision.xyz/txblock/EYPWs5XLuQ9TrygHtGLdk67vESmEmgsQaoSbBjuvXQBj If the enum is reduced in size, it still leads to errors down the road if its added to a bag for example: https://testnet.suivision.xyz/txblock/5d1E5FTLTZZq6uxySAMyXn34VtdxxBTRyfzb27hr2vab Reducing the size of the enum more (e.g. commenting out variants) resolves this issue.
In order to work with the limit we already tried refactoring the enum to use more subenums but this didn't help. Our module setup can't really be realized with a different setup so would love to get your feedback if its possible at all to increase the limit.
fyi we used to have problems at publishing with one huge enum with 37 variants and 72 fields which we split up in subenums as Justin mentioned, now we get the issue at runtime. Not sure we can fix this in a smooth way so creating this issue to pick up the conversation again about increasing the field limit number.
Could you also shed a light on the exact limits in place? @tzakian mentioned: "Note that enums in Move currently have the restriction(s) that they must have at most 127 variants, and at most 32 fields across all variants in the enum."
But it seems like in both cases we are not hitting the limits here (esp as the error occurs at runtime)
Hey there!
So had a look and both of these transactions are running into a different limit related to the maximum number of type nodes that can be created for a value's type layout (needed for serializing/deserializing the value). In particular, we have a runtime limit of 256 nodes in a given type layout, however the type layouts for the enums in question (due to their depth, and width) are hitting up against this limit and that is what is leading to this issue.
We're looking at how we might be able to increase this type layout limit without creating possible safety issues, but in the meantime probably the best course of action would be trying to simplify the types in that package (e.g., making them more generic/less enum intensive) as that can lower the size of type layout.
