-
Notifications
You must be signed in to change notification settings - Fork 789
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disputes raised due to RuntimeConstruction
error in pvf execution
#2863
Comments
The reason is probably that the VM was moved and as we don't clean up the cache anymore since #685. The solution should be that we include the host architecture as well in the artifact name. |
Ah no!
Also related: #661. The tl;dr is that I didn't have confidence to treat Good that this only happened on Rococo so far. We should make this a high-priority fix! |
You mean, do the considered refactor of preparation errors? This PR title is inaccurate because the logs indicate the error is in execution, not preparation. Indeed I was confused at first because preparation errors should never raise a dispute - will update the title. Or did you mean something else? |
RuntimeConstruction
error in pvf execution
Actually we can do this now, I forgot about this: #661 (comment) For the record, the concern was that the |
Considering the complexity of #2871 and the discussion therein, as well as the further complexity introduced by the hardening in #2742, as well as the eventual replacement of wasmtime by PolkaVM, it seems best to remove this persistence as it is creating more problems than it solves. ## Related Closes #2863
Considering the complexity of paritytech#2871 and the discussion therein, as well as the further complexity introduced by the hardening in paritytech#2742, as well as the eventual replacement of wasmtime by PolkaVM, it seems best to remove this persistence as it is creating more problems than it solves. ## Related Closes paritytech#2863
* cargo update -p mio * bump relayer version: v1.2.0 * Cargo.lock
The issue is happening on Rococo, logs: https://grafana.teleport.parity.io/goto/BQfD20FSg?orgId=1
WARN tokio-runtime-worker parachain::dispute-coordinator: Candidate 0x0008ce7fe58231c871fda90dd6fbf140fc5961bf0fad7301139340406a64bc63 considered invalid: ExecutionError("execute: execute error: RuntimeConstruction(Other(\"cannot deserialize module: compilation settings of module incompatible with native host: compilation setting \\\"has_avx512bitalg\\\" is enabled, but not available on the host\"))")
WARN tokio-runtime-worker parachain::pvf: execution worker concluded, error occurred: Invalid(WorkerReportedInvalid("execute: execute error: RuntimeConstruction(Other(\"cannot deserialize module: compilation settings of module incompatible with native host: compilation setting \\\"has_avx512bitalg\\\" is enabled, but not available on the host\"))")) artifact_id=ArtifactId { code_hash: 0x90efa66f83c794ea1ce93f4a7f019a389a6ba151493326bd790e49077515f369, executor_params_hash: 0x03170a2e7597b7b7e3d84c05391d139a62b157e78786d8c082f29dcf4c111314 } worker=Worker(2v1) worker_rip=false
WARN tokio-runtime-worker parachain::approval-voting: Detected invalid candidate as an approval checker. reason=ExecutionError("execute: execute error: RuntimeConstruction(Other(\"cannot deserialize module: compilation settings of module incompatible with native host: compilation setting \\\"has_avx512bitalg\\\" is enabled, but not available on the host\"))") candidate_hash=0xa9a745a082c2aadb0077a421b5902be4ef54f4c1f5d0da4871edd2ca65e0ca09 para_id=Id(2030) traceID=225508057066263142710214066364837014500
To answer why is this happening, requires more digging. One possible answer is the host VM type was changed. But, in any case we shouldn't raise a dispute for candidates that we can't check due to such errors.
CC @s0me0ne-unkn0wn @mrcnski
The text was updated successfully, but these errors were encountered: