-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
fix: error when actor panics directly #3697
Conversation
Yeah, this should not be a fatal error but one of the |
Okay, well, just so you know, there are a bunch of places in the runtime where Just to reiterate, the case where this kind of error happens should be extremely rare and this change would cause the message to not make it into a block in the first place. If I understand correctly and we allow this kind of message into a block, then another node applying this message is likely to not reach the same state conclusion anyway. I'm super new to the code base so I'm happy to take your advice on this. If you're still set on returning a |
7519bb7
to
4d9f8c3
Compare
This PR adds the `apply_message_failures` post condition to the schema. There's currently only 1 test that uses this `no-exit-code` but it currently does not error. If you want to see the new field in JSON output then you'll need to checkout the branch from filecoin-project/lotus#3697 and add a replace to go.mod `replace github.com/filecoin-project/lotus => ../lotus`. This also updates to lotus 0.7 and specs-actors 0.9.8. resolves #134
Ok, can we not use |
4d9f8c3
to
7b55625
Compare
Attempting to resolve filecoin-project/test-vectors#87, quoting @anorth:
I believe that returning a "fatal"
ActorError
instead ofSysErrSenderInvalid(1)
prevents the message from being recorded on chain since it's caught in ApplyMessage here.