-
Notifications
You must be signed in to change notification settings - Fork 671
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
Feat/async block proposal #4228
Conversation
bf23258
to
d5f53ad
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## next #4228 +/- ##
==========================================
+ Coverage 82.78% 82.94% +0.16%
==========================================
Files 429 430 +1
Lines 302897 303578 +681
==========================================
+ Hits 250756 251809 +1053
+ Misses 52141 51769 -372 ☔ View full report in Codecov by Sentry. |
/// - Miner signature is valid | ||
/// - Validate threshold signature of stackers | ||
/// - Validation of transactions by executing them agains current chainstate. | ||
/// This is resource intensive, and therefore done only if previous checks pass |
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.
It's really a shame that we can't easily overlap this with the similar code in NakamotoChainState
without substantial refactoring. Perhaps this is just going to have to be a back-burner issue.
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.
Yeah, I agree. The code overlap isn't so excessive, though, because most of the work here is already taking place through invocations of begin_tenure
, etc. There's also a repeated code block here that needs to be removed: the stacker signature check. That cannot be part of the proposal validation (because the proposal validation is occurring to decide whether or not to sign in the first place).
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. Thanks!
Seems your OpenAPI validation is failing |
debe795
to
d26812f
Compare
…o_block_burnchain()`
d26812f
to
96c4f9b
Compare
p | ||
}; | ||
|
||
let block = { |
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 wonder if I should use something like this rather than the test observer to validate the block written to stacker db in my .miners PR.
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 the approach you use in your PR is better for the .miners
check: you want to confirm that the miner thread's actual block matches the data read out of the stackerdb, not that an independently assembled block matches either of those.
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.
Looks good, I think there's a couple issues in the docs that need attention before merging
Used by stackers to validate a proposed Stacks block from a miner. | ||
|
||
**This endpoint will only accept requests over the local loopback network interface.** | ||
responses: |
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.
Where is the 4xx
error response for an invalid block?
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.
Okay I see that on a 202
results are returned via event observer. There are still situations where you can get a 400
response, like a NetError
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.
Right, those 400 responses are common to all API endpoints though.
@@ -693,6 +693,22 @@ impl ToSql for ThresholdSignature { | |||
} | |||
} | |||
|
|||
impl serde::Serialize for ThresholdSignature { |
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.
It looks like you are replacing the wsts::common::Signature
Serde format, which is kinda complex, with a simple hex string. Good call
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.
Yep, and this is already done for the SQL implementations, so it seemed like a straightforward improvement.
@@ -500,6 +506,23 @@ impl PeerNetwork { | |||
network | |||
} | |||
|
|||
pub fn set_proposal_thread(&mut self, thread: JoinHandle<()>) { |
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.
Should this check if self.block_proposal_thread
is None
first?
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 so -- the caller needs to have already checked this, because it shouldn't even get a JoinHandle
if the block_proposal_thread
is still running.
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Description
Adds the
/v2/block_proposal
endpoint with async processing and callback over the event observer interface.It does this by spawning a thread (if no such thread is currently running) and passing it a handle to an event dispatcher.
Applicable issues
/v2/block_proposal
endpoint #4084Todo