Skip to content

Conversation

@mts1715
Copy link

@mts1715 mts1715 commented Oct 24, 2025

Closes #7611
Aligns LatestPersistedSealedResult with the storage layer's context lock pattern introduced in #7364.

Changes
Updated LatestPersistedSealedResult.BatchSet() to accept lockctx.Proof as first parameter
Added runtime lock verification - requires caller to hold LockInsertCollection
Removed internal batchMu sync.Mutex in favor of external lock management via lockctx
Updated all tests to use storage.NewTestingLockManager() and unittest.WithLock()
Updated mocks to reflect new signature

Rationale
LockInsertCollection is used because:
BatchSet() is called within BlockPersister.Persist() which already holds this lock
All persistence operations (collections, events, results, progress) are committed in a single atomic batch
Collections storage requires LockInsertCollection for transaction indexing consistency
This ensures atomicity: either all data persists together or none

peterargue and others added 30 commits February 28, 2025 12:41
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Alexander Hentschel <[email protected]>
illia-malachyn and others added 28 commits September 16, 2025 18:03
Update apis to return executor metadata by reference
…er-2025-09-23

[DataAvailability] Merge master into feature/optimistic-sync 2025-09-23
…ider

[Access] Fix ExecutionResultInfoProvider for nodes bootstrapped after spork
…vents-endpoint

[Data availability] fork aware events endpoint
@mts1715 mts1715 self-assigned this Oct 24, 2025
@mts1715 mts1715 requested a review from a team as a code owner October 24, 2025 08:32
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.

[DataAvailability] Update LatestPersistedSealedResult module to use storage lock

3 participants