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

Stream sync stuck with persistent disk cache and single db transaction #4449

Open
GheisMohammadi opened this issue Jun 19, 2023 · 0 comments
Labels

Comments

@GheisMohammadi
Copy link
Contributor

Describe the bug
If a node uses the disk cache and tries to process a single transaction for the entire sync loop, the sync will break and the node will stop syncing.

To Reproduce
Steps to reproduce the behavior:

  1. Make sure stream sync is enabled
  2. in config file set the UseMemDB=false
  3. set the canRunCycleInOneTransaction=true (in syncing.go under api/service/stagedstreamsync)
    -- later this flag will be set dynamically by PR update the hardcoded settings in stream sync #4448
  4. Build
  5. Let node start syncing from a few thousands blocks behind the network. It won't get any new block and syncing won't go through.

Expected behavior
Node has to start syncing process and download the blocks until it reaches to current block

Additional context
The PR #4445 is combining the contexts, which can break disk access for ErigonDB. For example, it removes context.Background() and replaces it with a common context from stage.
to get the idea what is the reason of using background context, try writing a test with ErigonDB and creating a few goroutines, then commit some data to the same db. Your code has to open up a new transaction with another thread but same database and same context. It will not be able to write to disk while other routines are using the same database.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant