nethermind
nethermind copied to clipboard
Unified invalid blocks handling in logs
Changes
Before the change: If we reject a block with an invalid block hash, we don't know the extra data, so we can't determine who produced it. A shared/unified message has been introduced to address this issue.. Example:
We should add more things to InvalidBlockHelper in future, for example, bad blocks metrics, handling via debug_getBadBlocks.
Types of changes
What types of changes does your code introduce?
- [ ] Bugfix (a non-breaking change that fixes an issue)
- [ ] New feature (a non-breaking change that adds functionality)
- [ ] Breaking change (a change that causes existing functionality not to work as expected)
- [ ] Optimization
- [ ] Refactoring
- [ ] Documentation update
- [ ] Build-related changes
- [x] Other: Logging
Testing
Requires testing
- [x] Yes
- [ ] No
If yes, did you write tests?
- [ ] Yes
- [x] No
Notes on testing
I am going to review existing tests, logging change. Testing - don't merge