test: actor abort

[alanshaw]

TODO:

• apply_message_failures in vectors - do we still want to do that? (context)
• Some documentation for null receipts

Depends on:

• resolve lotus, test-vectors, statediff dependency cycle lotus#3688
• feat: chaos abort lotus#3733

Upstream fixes for broken tests (not blocking merge):

• fix: restrict actor exit codes to non-system codes lotus#3656
• fix: error when actor panics directly lotus#3697

resolves #87
resolves #15
closes #49

[willscott]

to confirm: on messages that fail to apply we get a null message receipt, but no other encoding within the test-vector json of the error code or other things around message failure?
My suspicion is that error codes would be a good thing to standardize and are worth including somewhere.

[alanshaw]

to confirm: on messages that fail to apply we get a null message receipt, but no other encoding within the test-vector json of the error code or other things around message failure?

Correct. Although, looks like this may not end up being the case... filecoin-project/lotus#3697

My suspicion is that error codes would be a good thing to standardize and are worth including somewhere.

Under usual circumstances the receipt will carry the exit/error code. Actors are expected to call Runtime.Abortf to fail with a standardized exit code. null receipts cater for the very exceptional case where the actor panics without using Runtime.Abortf. This could be in an actor dependency or because of an OOM for example. This type of error will have no interoperable error code or message to record in our vectors.

[raulk]

Maybe a more idiomatic way of doing this would be:

var receipt *schema.Receipt
if am.Result != nil {
    receipt = &schema.Receipt{
        ExitCode:    int64(am.Result.ExitCode),
        ReturnValue: am.Result.Return,
        GasUsed:     am.Result.GasUsed,
    }
}
b.vector.Post.Receipts = append(b.vector.Post.Receipts, receipt)

[raulk]

I wonder if we want to make the traces a slice of pointers []*types.ExecutionTrace, and leave a nil element for each message that doesn't have a result?

[raulk]

Nice, this is a lot more explicit.

[raulk]

apply_message_failures in vectors - do we still want to do that?

I think we want to be as declarative and explicit as possible. After all, a general goal of test vectors is to remove ambiguity and uncertainty. For machines, it might be redundant to have this index, but I anticipate that this explicit acknowledgement of which messages fail will be useful for when humans have to debug something.

Related: I like what you did with ApplicableMessage#Applied and I'm thinking we should add a Failed field to ApplicableMessage, and use that instead of nil checks everywhere. A nil can mean a lot of things, but Failed: true can only mean one thing.

We can also replace the Nil() predicate by a Failed() predicate, which makes the API a lot more semantic and self-descriptive, IMO.

[raulk]

This is OK and I'm happy to merge as-is. I'll open a follow-up issue to try to address the comments and the TODO items!