-
Notifications
You must be signed in to change notification settings - Fork 1k
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
always close cache warm chan to prevent blocking #14080
Conversation
@@ -93,13 +93,15 @@ func windowMin(latest, offset primitives.Slot) primitives.Slot { | |||
func (p *blobPruner) warmCache() error { | |||
p.Lock() | |||
defer p.Unlock() | |||
defer func() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does the order of the defer above for unlock matter? I suppose if it unlocks here this other defer is updating p.warmed without the lock?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
defers are always LIFO, so this code is correct (unlock happens after the channel is closed). But, I did anticipate this might confuse someone and thought about putting the unlock in the other deferred function, so I think I'll go ahead and do that.
* always close cache warm chan to prevent blocking * test that waitForCache does not block * combine defers to reduce cognitive overhead * lint --------- Co-authored-by: Kasey Kirkham <kasey@users.noreply.github.com>
What type of PR is this?
Bug fix
What does this PR do? Why is it needed?
5.0.4-rc.1
has a bug where invalid blobs in blob storage can cause the cache warmup code to fail to close the channel which other users of the cache wait on to indicate the cache is ready. This results in initial-sync (which does not use a timeout when requesting the cache) to hang indefinitely if there are truncated blobs in storage.This PR fixes the issue by ensuring the sentinel channel is always closed, even if the cache warmup call to the pruning func produces an error.