-
Notifications
You must be signed in to change notification settings - Fork 219
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: reinsert transactions from failed block #4675
fix: reinsert transactions from failed block #4675
Conversation
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.
Makes sense
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 - I agree with this approach
This looks fine, but it does kinda seem like what's the point in removing them in the first place. This will only catch the case where the mempool failed to process a mined block, but then again I don't know if this will catch it. |
4dc17c0
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, not for this PR, but in favour of splitting the comms logs up, maybe DHT+messaging, rpc and the rest.
I don't think outputting the byte contents of all outgoing messages is very useful
header_str, | ||
self.tag, | ||
self.body |
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.
Maybe the length rather?
comms/dht/src/logging_middleware.rs
Outdated
@@ -86,7 +91,7 @@ where | |||
} | |||
|
|||
fn call(&mut self, msg: R) -> Self::Future { | |||
trace!(target: LOG_TARGET, "{}{}", self.prefix_msg, msg); | |||
info!(target: LOG_TARGET, "{}{:?}", self.prefix_msg, msg); |
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.
Perhaps debug?
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, meant debug-level logging (going by the guide of whether a user would be interested in this information)
Co-authored-by: Stan Bondi <sdbondi@users.noreply.github.com>
* development: (72 commits) fix: reinsert transactions from failed block (tari-project#4675) fix: stray clippy error (tari-project#4685) fix(wallet): mark mined_height as null when pending outputs are cancelled (tari-project#4686) chore: updated dependancies (tari-project#4684) fix(p2p): remove DETACH flag usage (tari-project#4682) fix(comms): simplify and remove possibility of deadlock from pipelines and substream close (tari-project#4676) feat(ci): add default CI and FFI testing with custom dispatch (tari-project#4672) chore: remove broken test (tari-project#4678) fix: fix potential race condition between add_block and sync (tari-project#4677) fix deadlock (tari-project#4674) fix: add burn funds command to console wallet (see issue tari-project#4547) (tari-project#4655) v0.38.3 fix: fee estimate (tari-project#4656) fix(comms/messaging): fix possible deadlock in outbound pipeline (tari-project#4657) fix: replace Luhn checksum with DammSum (tari-project#4639) fix(core/sync): handle deadline timeouts by changing peer (tari-project#4649) fix(ci): libtor build on Ubuntu (tari-project#4644) chore: fix log (tari-project#4634) v0.38.2 fix(comms/rpc): detect early close in all cases (tari-project#4647) ...
Description
After removing transactions from the mempool from a failed validation, reinsert them to keep the valid ones
Motivation and Context
Currently, the implementation discards all transactions when validation fails. This is a pretty heavy approach, because the block may be incorrect in the header. There may even be an attack where a malicious user crafts a bad block and removes all transactions in the mempool.
In this approach, the transactions are reinserted into the mempool. If any of them are now invalid (e.g. double spends) they will be discarded
How Has This Been Tested?
existing tests, CI