Skip to content
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

Merged
merged 9 commits into from
Sep 5, 2022
Merged

Conversation

jmederosalvarado
Copy link
Member

@jmederosalvarado jmederosalvarado commented Sep 1, 2022

Changes:

  • Add failing test for case where we get the same new payload but we don't cache it, so we returned SYNCING instead of processing and returning VALID or INVALID
    • Fix: Check if block was processed when result is AlreadyKnown
  • Add failing test for case where we get the same new payload, which is invalid but won't be detected until processing, if the block processing queue is not empty we correctly return syncing the first time we get it, but we'll cache the wrong value for that payload, so the second time, if we still haven't processed the block we will return valid, even though the block is invalid and has not been processed.
    • Fix: we were setting the value in the cache to the result of the payload pre-processing validation and we were just ignoring the result of the processing.
  • After the above fixes, the 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 apply

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation Update
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • Other (please describe):

Testing

Requires testing

  • Yes
  • No

In case you checked yes, did you write tests??

  • Yes
  • No

Comments about testing

Probably good to run a few nodes?

Copy link
Contributor

@asdacap asdacap left a 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.

@jmederosalvarado jmederosalvarado force-pushed the fix-new-payload-handler-already-known branch from d0b9701 to 13448ad Compare September 1, 2022 14:28
@jmederosalvarado jmederosalvarado force-pushed the fix-new-payload-handler-already-known branch from f06befb to b16935a Compare September 2, 2022 02:29
};

validationMessage = e.ProcessingResult switch
{
ProcessingResult.QueueException => "Block cannot be added to processing queue.",
ProcessingResult.MissingBlock => "Block wasn't found in tree.",
ProcessingResult.Exception => blockProcessingThrewException,
Copy link
Contributor

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,
Copy link
Contributor

@MarekM25 MarekM25 Sep 5, 2022

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

@MarekM25 MarekM25 merged commit 8ffa8c1 into master Sep 5, 2022
@MarekM25 MarekM25 deleted the fix-new-payload-handler-already-known branch September 5, 2022 09:24
dceleda pushed a commit that referenced this pull request Sep 6, 2022
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants