Skip to content

Conversation

@Ayiga
Copy link
Member

@Ayiga Ayiga commented Aug 22, 2025

This PR:

Adds a check to fix a potential invariant where the start value of an inclusiveBlockRange is not guaranteed to precede the end value of the same inclusiveBlockRange.

Refactors the espressoBatchLoadingLoop to more closely match the blockLoadingLoop so they can be more easily compared. Should be reviewed by @QuentinI for correctness, and opinion.

Ayiga added 2 commits August 22, 2025 12:49
It is possible for the returned `inclusiveBlockRange` to can return a `start` value that
is greater than the `end` value.  This can be addressed by adding an extra check to
the return statement that causes it.

This changes adds a check to ensure that it doesn't return a start value that actually
follows the end value of the range.
It would be beneficial for the implementation of `espressoBatchLoadingLoop` to more
closely match the `blockLoadingLoop` implementation so that any deviations in their
implementation can be more easily identified.

This change modifies the `espressoBatchLoadingLoop` method to more closely mirror
the `blockLoadingLoop` implementation.
// State empty, just enqueue all unsafe blocks
if len(l.queuedBlocks) == 0 {
return inclusiveBlockRange{safeL2.Number + 1, newSyncStatus.UnsafeL2.Number}, ActionEnqueue
if newSyncStatus.UnsafeL2.Number <= safeL2.Number+1 {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nit: can we make a firstUnsafeBlock := safeL2.Number + 1 or something like that? I feel like the next few lines would be easier to read then.

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.

3 participants