-
Notifications
You must be signed in to change notification settings - Fork 402
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
Fixes in new payload handler #4511
Conversation
This enables to test with different cache sizes, very useful for testing without cache for example.
src/Nethermind/Nethermind.Merge.Plugin/Handlers/V1/NewPayloadV1Handler.cs
Outdated
Show resolved
Hide resolved
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 for the additional comment/doc.
d0b9701
to
13448ad
Compare
f06befb
to
b16935a
Compare
src/Nethermind/Nethermind.Merge.Plugin/Handlers/V1/NewPayloadV1Handler.cs
Show resolved
Hide resolved
src/Nethermind/Nethermind.Merge.Plugin/Handlers/V1/NewPayloadV1Handler.cs
Outdated
Show resolved
Hide resolved
src/Nethermind/Nethermind.Merge.Plugin/Handlers/V1/NewPayloadV1Handler.cs
Show resolved
Hide resolved
src/Nethermind/Nethermind.Merge.Plugin/Handlers/V1/NewPayloadV1Handler.cs
Outdated
Show resolved
Hide resolved
src/Nethermind/Nethermind.Merge.Plugin/Handlers/V1/NewPayloadV1Handler.cs
Outdated
Show resolved
Hide resolved
}; | ||
|
||
validationMessage = e.ProcessingResult switch | ||
{ | ||
ProcessingResult.QueueException => "Block cannot be added to processing queue.", | ||
ProcessingResult.MissingBlock => "Block wasn't found in tree.", | ||
ProcessingResult.Exception => blockProcessingThrewException, |
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.
Just wondering... why removed?
// or the block was processed and it's valid. the case where the block was processed and is | ||
// invalid is not a possibility, because it would have been intercepted by the InvalidChainTracker | ||
// earlier in the handling pipeline. if processed return VALID, otherwise null so that it's process a few lines below | ||
AddBlockResult.AlreadyKnown => _blockTree.WasProcessed(block.Number, block.Hash!) ? ValidationResult.Valid : null, |
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 would be great if we log such cases in different way
* Parametrize latest block cache size This enables to test with different cache sizes, very useful for testing without cache for example. * Add failing test for AlreadyKnown blocks * Workaround issue with blocks that are AlreadyKnown and not cached * Add failing test where we accept invalid block * Fix issue where we might set a block as valid in cache even if processing fails * Don't reprocess blocks that have already been processed * Simplify validation logic after removing AlreadyKnown case * Rename CacheResult to TryCacheResult to indicate conditional caching * Whitelist VALID and INVALID instead of blacklisting SYNCING when caching
Changes:
AlreadyKnown
AlreadyKnown
case was unreachable, so the code was simplified a little thanks to this.Types of changes
What types of changes does your code introduce?
Put an
x
in the boxes that applyTesting
Requires testing
In case you checked yes, did you write tests??
Comments about testing
Probably good to run a few nodes?