-
Notifications
You must be signed in to change notification settings - Fork 142
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
Pending blocks might not be submitted to DA #1548
Comments
Simple and effective solution is to modify the code to ensure that height of the latest block successfully submitted to DA is persisted in store. After restart we need to continue DA submission. On the implementation level, there are several possibilities:
|
@tzdybal Can I pick this? Option 2 sounds better. We can have a cron-like go-routine which runs every X number of seconds and queries Y number of blocks from DB using a prefix filter. X and Y can vary based on the lag. What do you think? |
Hi @arhamj, I'm currently tackling this issue. Thanks for understanding! |
TestPendingBlocks should fail to proof the existence of the bug. This commit introduces a new test to check pending blocks as described in issue #1548. It mimics the behavior of a node producing blocks, stopping and restarting, then producing more blocks.
TestPendingBlocks should fail to proof the existence of the bug. This commit introduces a new test to check pending blocks as described in issue #1548. It mimics the behavior of a node producing blocks, stopping and restarting, then producing more blocks.
TestPendingBlocks should fail to proof the existence of the bug. This commit introduces a new test to check pending blocks as described in issue #1548. It mimics the behavior of a node producing blocks, stopping and restarting, then producing more blocks.
TestPendingBlocks should fail to proof the existence of the bug. This commit introduces a new test to check pending blocks as described in issue #1548. It mimics the behavior of a node producing blocks, stopping and restarting, then producing more blocks.
TestPendingBlocks should fail to proof the existence of the bug. This commit introduces a new test to check pending blocks as described in issue #1548. It mimics the behavior of a node producing blocks, stopping and restarting, then producing more blocks.
<!-- Please read and fill out this form before submitting your PR. Please make sure you have reviewed our contributors guide before submitting your first PR. --> ## Overview This PR creates a new test to check pending blocks as described in issue #1548. It mimics the behavior of a node producing blocks, stopping and restarting, then producing more blocks. Looking at commit history you can check that test was initially failing and then was fixed. New implementation of `pendingBlocks` is safer because its data is persisted in store. If node is restarted, block submission to DA will restart when it ended. The worst case scenario (very unlikely), where `pendingBlocks` can't save information to store, results in resubmission of blocks already submitted to DA, which is only the extra cost. The solution ensures that all the blocks are successfully submitted to DA. This PR is bigger than I expected, and because of that I will work on #1524 and limiting the number of blocks returned by `getPendingBlocks` in follow-up PR. Resolves #1548 Resolves #457 <!-- Please provide an explanation of the PR, including the appropriate context, background, goal, and rationale. If there is an issue with this information, please provide a tl;dr and link the issue. --> ## Checklist <!-- Please complete the checklist to ensure that the PR is ready to be reviewed. IMPORTANT: PRs should be left in Draft until the below checklist is completed. --> - [x] New and updated code has appropriate documentation - [x] New and updated code has new and/or updated testing - [x] Required CI checks are passing - [x] Visual proof for any user facing features like CLI or documentation updates - [x] Linked issues closed with keywords <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Introduced a new mock generation command for enhanced testing capabilities. - Added functionality for improved block management and submission to Data Availability layers. - Enhanced metadata management in the store for better data handling and retrieval. - Implemented new testing functions and improved existing ones for better coverage and reliability. - **Bug Fixes** - Fixed handling of empty block submissions to prevent errors during block publishing. - **Refactor** - Refactored block management to improve code efficiency and readability. - Consolidated mock application creation logic in integration tests for better maintainability. - **Tests** - Expanded testing suite with new tests for block submission, metadata operations, and mock DA interactions. - **Chores** - Updated dependencies and imports across various files to enhance functionality and testing. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Currently, blocks are submitted to DA via
pendingBlocks
queue. This queue is stored in memory, so in case of a restart of the aggregator node, the information might be lost. After the restart aggregator will continue to produce blocks, and submit those new blocks to DA, but all that were pending before the restart were lost so they will not be submitted to DA.This causes issues since if any blocks are not in DA, full nodes are not able to sync.
Additionally:
Example:
pendingBlocks
contains blocks between 1000 and 1010.The text was updated successfully, but these errors were encountered: