Skip to content

Fix data race on finality checkpoint - #84

Open
damilolaedwards wants to merge 1 commit into
ethpandaops:masterfrom
damilolaedwards:fix/finality-data-race
Open

Fix data race on finality checkpoint#84
damilolaedwards wants to merge 1 commit into
ethpandaops:masterfrom
damilolaedwards:fix/finality-data-race

Conversation

@damilolaedwards

Copy link
Copy Markdown

Summary

FetchFinality wrote to n.finality without holding a lock, while Finality() read it directly with no synchronization. The epoch cron, the finalized_checkpoint event handler, and any consumer calling FetchFinality directly can all run this concurrently, which is a real data race, not just staleness: a reader can observe a partially published Finality struct.

Fix adds a finalityMu RWMutex and guards the read-compare-write in FetchFinality and the read in Finality(), matching the existing pattern already used for spec and genesis.

Test plan

  • Added TestFinalityMutex in pkg/beacon/beacon_test.go exercising FetchFinality and Finality() concurrently from 16 goroutines
  • Confirmed the test fails under -race against the old code and passes clean against the fix
  • go build ./..., go vet ./..., go test -race ./... all green

FetchFinality wrote to n.finality without holding a lock while
Finality() read it directly. The epoch cron, the finalized checkpoint
event handler, and any consumer calling FetchFinality could all run
this concurrently. Added finalityMu and guarded both the read compare
write in FetchFinality and the read in Finality(), the same pattern
already used for spec and genesis.
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.

1 participant