-
Notifications
You must be signed in to change notification settings - Fork 673
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
2.05 integration testing: exact costs matching in miner and follower: #2913 #2916
Conversation
…s, and replace all instances of doing this ad-hoc with a call to this method
… signal handler report the signal received to the user-supplied callback.
…trlc crate's platform-specific deps
…ng -- this is an inevitable consequence of having multiple runloops
…ibc methods for recording that a signal has been caught.
Use mmap on MARF connections
.expect("BUG: block_cost + microblock_cost < block_cost"); | ||
|
||
// if we get here, then we need to reset the block-cost back to 0 because this begins the | ||
// block defined by this miner. |
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.
lol copypasta
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 specifically altered "epoch" to "block"! Is it more confusing? I'm not sure. But having two definitions of epochs is terrifying to me!
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.
No, not a problem at all. Just happened to notice that almost-the-same comment is in append_block()
;)
pub const PATH_BURN_BLOCK_SUBMIT: &str = "new_burn_block"; | ||
pub const PATH_BLOCK_PROCESSED: &str = "new_block"; | ||
pub const PATH_ATTACHMENT_PROCESSED: &str = "attachments/new"; | ||
|
||
#[derive(Clone, Serialize, Deserialize)] | ||
pub struct MinedBlockEvent { |
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.
Is this something the sidecar will use, or is this only meant for testing? Fine either way; just curious.
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.
Probably not API operators, but it's something that could be useful down the road for miners (or running a mock miner for analysis) -- event observers could get all sorts of information about their miner this way. Right now, it's really only useful for testing, but I figured it could be made into something more generally useful at some point.
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 @kantai
EDIT: can we make sure that this change doesn't break any of the overflow tests?
Yep -- that's the remaining item here, I need to look at that microblock integration test. |
…ntegration_test to match new expected behavior
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. |
This PR does a few things:
develop
tonext-costs
new_block
eventsmined_block
event that relays information about mined, but not necessarily won blocks from a miner.