Closed austinabell closed 4 years ago
@austinabell On thinking of this, I suspect we should take the inverse approach here: let implementors decide which test vectors they want to rule out for their implementations, and submit a PR to add the appropriate selector.
I'm thinking we can follow the pattern:
"lotus:exclude": true
"forest:exclude": true
"fuhon:exclude": true
WDYT?
@austinabell On thinking of this, I suspect we should take the inverse approach here: let implementors decide which test vectors they want to rule out for their implementations, and submit a PR to add the appropriate selector.
I'm thinking we can follow the pattern:
"lotus:exclude": true
"forest:exclude": true
"fuhon:exclude": true
WDYT?
Yeah I'm fine with just leaving as skipping on our end for now, also so we don't lock into anything specific. I'll just wait until the test vectors build up instead of doing for each one
Feel free to submit modifications to the builder scripts to add any exclusion tags that your driver/runner identify.
Within the chaos actor, there are boolean flags from parameters that set address and Cid to
address.Undef
andcid.Undef
which can sometimes lead to Lotus specific checks occurring. Since these types should never in practice arise (or it's a bug in Lotus and they cannot be deserialized as that) would be nice to have some indication that it is testing a Lotus specific code path/ sanity check.Nbd if not changed, but would be appreciated if non-protocol defined functionality tests would be denoted in some way so it's more easily identified by any other client using the submodule