-
Notifications
You must be signed in to change notification settings - Fork 677
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
Add SignerEvent::NewNakamotoBlock and do not update a block to GloballyAccepted until event arrives #5516
base: develop
Are you sure you want to change the base?
Conversation
7fefa19
to
c107ca3
Compare
…lyAccepted until node processes the new block successfully Signed-off-by: Jacinta Ferrant <jacinta@trustmachines.co>
c107ca3
to
1855264
Compare
Signed-off-by: Jacinta Ferrant <jacinta@trustmachines.co>
bf41d77
to
57848b3
Compare
… into feat/signer-subscribe-to-block-events
Signed-off-by: Jacinta Ferrant <jacinta@trustmachines.co>
a25bd75
to
f2da5f2
Compare
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.
I think an integration test would be needed, otherwise LGTM!
Is /new_block
always sent to an observer, regardless of the event keys they've set? It seems so, but I'd want to be 100% on that
Signed-off-by: Jacinta Ferrant <jacinta@trustmachines.co>
f2da5f2
to
d4860f8
Compare
It is always yes. But I cannot for the life of me test this without so much jankiness that I think it defeats the purpose. We already have multiple tests that pass through this exact code so I think its fine to not have an integration test (essentially order of ops is:
If 2 and 3 happen out of order, it doesn't make operational difference. We don't care if we are first globally and then see 70% or if we are first locally accepted and then mark globally once new block arrives. EDIT: basically I cannot force a unique situation that PROVES that global acceptance happened ONLY at the new burn block arrival vs the reading of the nodes chain tip. I essentially need access to the signerdb and see the order of its updates is as expected and even then its not exactly unique. We have two instances where a block gets marked globally accepted and its very hard to force a scenario that does not cause the other to hit first/prove which one actually hit. Closest to is to forcibly propose a sister block with all other overrides disabled. |
Signed-off-by: Jacinta Ferrant <jacinta@trustmachines.co>
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.
LGTM!
Signed-off-by: Jacinta Ferrant <jacinta@trustmachines.co>
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.
LGTM!
… into feat/signer-subscribe-to-block-events
libsigner/src/events.rs
Outdated
))); | ||
} | ||
#[derive(Debug, Deserialize)] | ||
struct TempBlockEvent { |
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.
Instead of making a bespoke and scoped struct, it might be cleaner to just add a fn from_slice(bytes: &[u8]) -> Result<SignerEvent<T>, EventError>
function to SignerEvent<T>
. Then, you could put all of the decode logic into that function, and just pass in body.as_bytes()
.
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.
I don't think I fully understand what you mean by passing in body.as_bytes(). But I did make a more generic process_event function that will correctly deserialize the request bytes so long as the event implements serde and try_from for SignerEvent.
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.
This looks great. Thank you for addressing this! Just a few minor comments before approving.
I like what you've done to clean up the test flags. Do you think you could take a moment and add a couple sentences on what each one does (or open an issue for doing so if it's too out-of-scope), so future test authors know how to use them? Thanks!
Good idea! Will do now! |
… into feat/signer-subscribe-to-block-events
Signed-off-by: Jacinta Ferrant <jacinta@trustmachines.co>
… into feat/signer-subscribe-to-block-events
Signed-off-by: Jacinta Ferrant <jacinta@trustmachines.co>
… into feat/signer-subscribe-to-block-events
061a93e
to
2a4371f
Compare
Signed-off-by: Jacinta Ferrant <jacinta@trustmachines.co>
… into feat/signer-subscribe-to-block-events
Signed-off-by: Jacinta Ferrant <jacinta@trustmachines.co>
Closes: #5514