-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Fix some unjustified disputes #6103
Changes from 9 commits
6a5df50
55d8d01
8d078cf
84a135a
f81357b
7051858
5159879
a88f697
3198c8d
a3fa89d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -527,8 +527,9 @@ async fn validate_candidate_exhaustive( | |
Err(e) => { | ||
gum::info!(target: LOG_TARGET, ?para_id, err=?e, "Invalid candidate (validation code)"); | ||
|
||
// If the validation code is invalid, the candidate certainly is. | ||
return Ok(ValidationResult::Invalid(InvalidCandidate::CodeDecompressionFailure)) | ||
// Code already passed pre-checking, if decompression fails now this most likley means | ||
// some local corruption happened. | ||
return Err(ValidationFailed("Code decompression failed".to_string())) | ||
}, | ||
}; | ||
|
||
|
@@ -560,7 +561,6 @@ async fn validate_candidate_exhaustive( | |
|
||
match result { | ||
Err(ValidationError::InternalError(e)) => Err(ValidationFailed(e)), | ||
|
||
Err(ValidationError::InvalidCandidate(WasmInvalidCandidate::HardTimeout)) => | ||
Ok(ValidationResult::Invalid(InvalidCandidate::Timeout)), | ||
Err(ValidationError::InvalidCandidate(WasmInvalidCandidate::WorkerReportedError(e))) => | ||
|
@@ -569,9 +569,13 @@ async fn validate_candidate_exhaustive( | |
Ok(ValidationResult::Invalid(InvalidCandidate::ExecutionError( | ||
"ambiguous worker death".to_string(), | ||
))), | ||
Err(ValidationError::InvalidCandidate(WasmInvalidCandidate::PrepareError(e))) => | ||
Ok(ValidationResult::Invalid(InvalidCandidate::ExecutionError(e))), | ||
|
||
Err(ValidationError::InvalidCandidate(WasmInvalidCandidate::PrepareError(e))) => { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually now that I revisit this, this should be fixed at one layer down already: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If this is merged, actually more cleanup will be needed:
Reason we no longer differentiate. During pre-checking we always assume invalid, just to be on the safe side. During preparation, we never want to raise a dispute if preparation fails (as it previously passed pre-checking), so we never want it to be of state There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Differentiation between the two error types (deterministic and non deterministic) still makes sense. For deterministic errors happening in preparation, we should print a big fat error. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
You can call There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. I arrived at the conclusion that the distinction is very useful. Non spurious errors, suggest some major issue like a hardware fault - the very least, they should have a higher log level. |
||
// In principle if preparation of the `WASM` fails, the current candidate can not be the | ||
// reason for that. So we can't say whether it is invalid or not in addition with | ||
// pre-checking enabled only valid runtimes should ever get enacted, so we can be | ||
// reasonably sure that this is some local problem on the current node. | ||
Err(ValidationFailed(e)) | ||
}, | ||
Ok(res) => | ||
if res.head_data.hash() != candidate_receipt.descriptor.para_head { | ||
gum::info!(target: LOG_TARGET, ?para_id, "Invalid candidate (para_head)"); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does every network now have pre-checking turned on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the node side, as soon as people upgrade to 0.9.30 (#5977). In the runtime, Kusama and Polkadot still don't.
Someone needs to submit a motion I suppose.