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

Potential race condition for locking flat storage updates #11602

Open
Longarithm opened this issue Jun 17, 2024 · 0 comments
Open

Potential race condition for locking flat storage updates #11602

Longarithm opened this issue Jun 17, 2024 · 0 comments
Labels
A-storage Area: storage and databases

Comments

@Longarithm
Copy link
Member

There is a FlatStorageInner::move_head_enabled field to lock flat storage updates if we need to make snapshot at the epoch boundary. However, it is set to false only when state snapshot request is sent. It means that if request is extremely late, flat storage will remain unlocked and will pass the epoch boundary, and after that it will be impossible to make epoch boundary snapshot.

We probably don't hit it because the gap between receiving request and passing the epoch is big enough, but the proper solution is to lock and unlock flat storage at the Client side, as it is responsible for flat storage updates.

@Longarithm Longarithm added the A-storage Area: storage and databases label Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-storage Area: storage and databases
Projects
None yet
Development

No branches or pull requests

1 participant