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

BlobSidecar pool immediate fetch for non-current-slot + prepare for data unavailable retry #7103

Merged
merged 3 commits into from
May 8, 2023

Conversation

tbenr
Copy link
Contributor

@tbenr tbenr commented May 5, 2023

  • Renames pool's onBlobSidecarsFromSync method to onCompletedBlockAndBlobSidecars, moving away from flow-based name to a feature-based one
  • Splits FAILED_DATA_AVAILABILITY_CHECK block import failure in two reasons:
    • FAILED_DATA_AVAILABILITY_CHECK_INVALID: data was there but validation failed
    • FAILED_DATA_AVAILABILITY_CHECK_NOT_AVAILABLE: data wasn't available
  • Modifies the BlobSidecar pool to try to fetch immediately when tracked data (block\blobs) are for a past slot

The "not available" one will be used to trigger a retry (on a dedicated PR)

related to #7112

Documentation

  • I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

  • I thought about adding a changelog entry, and added one if I deemed necessary.

@tbenr tbenr force-pushed the complete_block_import_logic branch from 4213f30 to fb8fd4f Compare May 8, 2023 09:32
@tbenr tbenr marked this pull request as ready for review May 8, 2023 09:32
@tbenr tbenr changed the title BlobSidecar pool immediate fetch for non-current-slot + prepare for data unavailable retry and BlobSidecar pool immediate fetch for non-current-slot + prepare for data unavailable retry May 8, 2023
Copy link
Contributor

@zilm13 zilm13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just minor nitpicks

@@ -384,7 +380,7 @@ Optional<Duration> calculateFetchDelay(final SlotAndBlockRoot slotAndBlockRoot)
final UInt64 finalTime =
targetMillis.min(upperLimitRelativeToAttDue).max(nowMillis.plus(MIN_WAIT_MILLIS));

return Optional.of(Duration.ofMillis(finalTime.minus(nowMillis).intValue()));
return Duration.ofMillis(finalTime.minus(nowMillis).intValue());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure but maybe we need to protect it there with minusMinZero?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, time provider should be guaranteed to be monotonic

@tbenr tbenr enabled auto-merge (squash) May 8, 2023 12:29
@tbenr tbenr merged commit 6b0a670 into Consensys:master May 8, 2023
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.

2 participants