-
Notifications
You must be signed in to change notification settings - Fork 741
Add error logs for unexpected proposervm BuildBlock failures #1832
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
Conversation
p.vm.ctx.Log.Error("unexpected build block failure", | ||
zap.String("reason", "failed to generate proposervm block header"), | ||
zap.Stringer("parentID", parentID), | ||
zap.Stringer("blkID", innerBlock.ID()), | ||
zap.Error(err), | ||
) |
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.
Erroring here technically won't cause an invariant break... However, it's unexpected so I felt like logging an error here still made sense.
zap.String("reason", "failed to calculate required timestamp delay"), | ||
zap.Stringer("parentID", parentID), | ||
zap.Error(err), | ||
) | ||
return nil, err | ||
} | ||
|
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.
Notice that we do not log an error below here if if delay < minDelay {
as that can happen normally and is handled gracefully.
Why this should be merged
Failing to build a block inside the proposervm unexpectedly can violate the consensus invariant that
BuildBlock
will be called at least once after receiving aPendingTxs
message.How this works
If the proposervm fails to build a block outside of the inner vm's control, an error should be logged. The exception to this is if the proposervm windower hasn't progressed far enough to attempt to build a block. In this case, we manually mock a
PendingTxs
message from the inner VM.How this was tested
N/A