-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Do not swallow the errors from wasmtime #11848
Description
Several Polkadot validators reported errors that looked like the following:
Jul 15 11:04:45 kusama-md polkadot[794128]: 2022-07-15 11:04:45 ⛓ Native runtime: kusama-9260 (parity-kusama-0.tx12.au2)
Jul 15 11:04:54 kusama-md polkadot[794128]: 2022-07-15 11:04:54 Cannot create a runtime error=Other("cannot create module: compilation settings are not compatible with the native host")
Jul 15 11:04:55 kusama-md polkadot[794128]: Error:
Jul 15 11:04:55 kusama-md polkadot[794128]: 0: Error at calling runtime api: Failed to get runtime version: cannot create module: compilation settings are not compatible with the native host
Jul 15 11:04:55 kusama-md polkadot[794128]: 1: Failed to get runtime version: cannot create module: compilation settings are not compatible with the native host
They managed to identify that the error happened due to virtualization and KVM. It would be interesting to know what happened there exactly. However, we cannot as of now. wasmtime uses anyhow to provide rich errors, but we convert the error to string early losing all that additional information. Also, note that there is some context in the error reported but it is very silly since some parts are duplicated.
From my experience, anyhow showed to be a very convenient way to handle errors. It allows for capturing context precisely and it is easy to use. A small downside is that it requires allocation but I don't think that the code is nearly hot to make this a problem. Ideally, we convert the whole error reporting path at least for the execution/state machine into using anyhow.
Alternatively, we can just patch up this particular place locally by printing the whole error.