Skip to content

Commit bd39edc

Browse files
Merge pull request #6976 from onflow/alex/result-approvals-godoc
documentation of storage abstraction interface `storage.ResultApprovals`
2 parents ad1076f + 43eae7d commit bd39edc

File tree

1 file changed

+28
-4
lines changed

1 file changed

+28
-4
lines changed

storage/approvals.go

Lines changed: 28 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -4,17 +4,41 @@ import (
44
"github.com/onflow/flow-go/model/flow"
55
)
66

7+
// ResultApprovals implements persistent storage for result approvals.
8+
// Implementations of this interface must be concurrency safe.
9+
//
10+
// CAUTION suitable only for _Verification Nodes_ for persisting their _own_ approvals!
11+
// - In general, the Flow protocol requires multiple approvals for the same chunk from different
12+
// verification nodes. In other words, there are multiple different approvals for the same chunk.
13+
// - Internally, ResultApprovals populates an index from Executed Chunk ➜ ResultApproval. This is
14+
// *only safe* for Verification Nodes when tracking their own approvals (for the same ExecutionResult,
15+
// a Verifier will always produce the same approval)
716
type ResultApprovals interface {
817

9-
// Store stores a ResultApproval
18+
// Store stores a ResultApproval by its ID.
19+
// No errors are expected during normal operations.
1020
Store(result *flow.ResultApproval) error
1121

12-
// Index indexes a ResultApproval by result ID and chunk index
22+
// Index indexes a ResultApproval by result ID and chunk index.
23+
//
24+
// CAUTION: the Flow protocol requires multiple approvals for the same chunk from different verification
25+
// nodes. In other words, there are multiple different approvals for the same chunk. Therefore, the index
26+
// Executed Chunk ➜ ResultApproval ID (populated here) is *only safe* to be used by Verification Nodes
27+
// for tracking their own approvals.
28+
//
29+
// For the same ExecutionResult, a Verifier will always produce the same approval. Therefore, this operation
30+
// is idempotent, i.e. repeated calls with the *same inputs* are equivalent to just calling the method once;
31+
// still the method succeeds on each call. However, when attempting to index *different* ResultApproval IDs
32+
// for the same key (resultID, chunkIndex) this method returns an exception, as this should never happen for
33+
// a correct Verification Node indexing its own approvals.
34+
// No errors are expected during normal operations.
1335
Index(resultID flow.Identifier, chunkIndex uint64, approvalID flow.Identifier) error
1436

15-
// ByID retrieves a ResultApproval by its ID
37+
// ByID retrieves a ResultApproval by its ID.
38+
// Returns [storage.ErrNotFound] if no Approval with the given ID has been stored.
1639
ByID(approvalID flow.Identifier) (*flow.ResultApproval, error)
1740

18-
// ByChunk retrieves a ResultApproval by result ID and chunk index
41+
// ByChunk retrieves a ResultApproval by result ID and chunk index.
42+
// Returns [storage.ErrNotFound] if no Approval for the given key (resultID, chunkIndex) has been stored.
1943
ByChunk(resultID flow.Identifier, chunkIndex uint64) (*flow.ResultApproval, error)
2044
}

0 commit comments

Comments
 (0)