[Access] Add draft of access api error framework #7106

peterargue · 2025-02-28T20:43:57Z

Experimenting with a potential framework we could use within the access APIs to improve error handling and make it more consistent across the different api types.

Some general comments about changes:

The backend api interface should handle all irrecoverable exceptions and only return benign errors. Callers into the backend can treat any unclassified errors as "internal errors" that abort request processing.
The backend should map errors into one of the access sentinel errors, which in turn have mappings into protocol specific (rest/grpc/websockets/etc) representations.

peterargue · 2025-02-28T21:48:45Z

engine/access/rest/common/error.go

+
+// ErrorToStatusError converts an Access API error into a grpc status error. The input may either
+// be a status.Error already, or an access sentinel error.
+func ErrorToStatusError(err error) StatusError {


each API has unique error reporting protocols (grpc vs rest vs websockets). Create API specific converters that return the appropriate mapping from access sentinels.

peterargue · 2025-02-28T21:51:14Z

engine/access/rpc/backend/backend.go

-		// it is possible for a client to request a finalized block from us
-		// containing some collection, then get a not found error when requesting
-		// that collection. These clients should retry.
-		err = rpc.ConvertStorageError(fmt.Errorf("please retry for collection in finalized block: %w", err))


backend should stop returning grpc status codes, and instead return access sentinel errors

peterargue · 2025-02-28T21:57:25Z

engine/access/rpc/backend/backend.go

-		if err != nil {
-			return fmt.Errorf("could not ping collection node: %w", err)
+		if _, err := b.staticCollectionRPC.Ping(ctx, &accessproto.PingRequest{}); err != nil {
+			return status.Errorf(status.Code(err), "could not ping collection node: %v", err)


I doubt this is actually used by anyone. I'm tempted to remove it

peterargue · 2025-03-04T20:23:48Z

access/errors.go

+// Otherwise, it throws an irrecoverable exception
+// Note: this method will not unwrap the error. the passed error must be an instance of a sentinel
+// error.
+func RequireAccessError(ctx context.Context, err error) error {


This can be used for more complex endpoints that call into other methods to ensure all unexpected errors are handled.

you could add your comment as context to the goDoc.

durkmurder

Very good job, I like this approach a lot and I think it makes sense considering the fact we are dealing with access API. My only comment would be that we need this clearly documented and defined somewhere.

It seems we agree on the fact that when dealing with protocol layer components we need to ensure that any error returned from the protocol layer is an expected error, everything else is considered as an unexpected behavior and leads to an irrecoverable exception. Using your approach we are doing this check at latest at the "backend" level and all higher level abstractions like the access API is dealing only with benign errors. As I said, I support that as long as we have a particular place where such error handling takes place. Creating a guideline will result in improved clarity and better code structure in general since it will be easier for engineers to argue about safety of the logic.

Correct me I am wrong but eventually each function from "backend" that implements some endpoint must include RequireNoError/RequireErrorIs/RequireAccessError, this way we ensure that only benign errors are propagated to the caller.

engine/access/rpc/backend/backend_network.go

peterargue · 2025-03-05T20:29:19Z

Correct me I am wrong but eventually each function from "backend" that implements some endpoint must include RequireNoError/RequireErrorIs/RequireAccessError, this way we ensure that only benign errors are propagated to the caller.

Yes, exactly.

AlexHentschel

preliminary set of minor comments

AlexHentschel · 2025-03-15T02:40:47Z

access/errors.go

+func NewOutOfRangeError(err error) OutOfRangeError {
+	return OutOfRangeError{err: err}
+}


[optional] since you are mentioning it:

flow-go/access/errors.go

Lines 139 to 140 in df07206

// This is a more specific version of DataNotFoundError, where the data is known to eventually exist, but

// currently is not known.

we could also implement it accordingly

Suggested change

func NewOutOfRangeError(err error) OutOfRangeError {

return OutOfRangeError{err: err}

}

func NewOutOfRangeError(err error) error {

return NewDataNotFoundError("OutOfRange", OutOfRangeError{err: err})

}

similarly for the PreconditionFailedError below, which you are identifying as special sub-cases of InvalidRequestError

AlexHentschel

I like the approach very much. It would be great, if you could add minimal documentation to the Access API interface and the corresponding protocol-level implementation where the critical error checks have to happen.

suggestion for the Access API interface

// API provides all public-facing functionality of the Flow Access API.
// CAUTION: SIMPLIFIED ERROR HANDLING
//   - All errors returned by this API are guaranteed to be benign. The
//     node can continue normal operations after such errors.
//   - To prevent delivering incorrect results to clients, in case of an
//     error, all other return values should be discarded.
type API interface {

Essentially, we are documenting the requirement for all implementations of the interface:

all implementations have to crash on anything except known benign errors

I am thinking about implementations like

flow-go/engine/access/rpc/backend/backend_execution_results.go

Line 15 in df07206

func (b *backendExecutionResults) GetExecutionResultForBlockID(ctx context.Context, blockID flow.Identifier) (*flow.ExecutionResult, error) {

flow-go/engine/access/rpc/backend/backend_execution_results.go

Lines 25 to 26 in df07206

    
           // GetExecutionResultByID gets an execution result by its ID. 
        
           func (b *backendExecutionResults) GetExecutionResultByID(ctx context.Context, id flow.Identifier) (*flow.ExecutionResult, error) {

This being documented only at the interface level bears the risk of this requirement accidentally being overlooked while updating the implementations. I think these risks are reasonably mitigated by just copying this documentation to all protocol-level backend implementations.

GetExecutionResultForBlockID could read something like:

 // GetExecutionResultForBlockID gets an execution result by ID of the executed block
 //
 // CAUTION: this layer SIMPLIFIES the ERROR HANDLING convention
 // As documented in the [access.API], which we partially implement with this function
 //   - All errors returned by this API are guaranteed to be benign. The node can continue normal operations after such errors.
 //   - Hence, we MUST check here and crash on all errors *except* for those known to be benign in the present context!
 func (b *backendExecutionResults) GetExecutionResultForBlockID(ctx context.Context, blockID flow.Identifier) (*flow.ExecutionResult, error) {

I tried to make the wording quite generic, so you can just copy the "caution"-block, e.g.

GetExecutionResultByID's goDoc would extend to:

 // GetExecutionResultByID gets an execution result by its ID.
 //
 // CAUTION: this layer SIMPLIFIES the ERROR HANDLING convention
 // As documented in the [access.API], which we partially implement with this function
 //   - All errors returned by this API are guaranteed to be benign. The node can continue normal operations after such errors.
 //   - Hence, we MUST check here and crash on all errors *except* for those known to be benign in the present context!
 func (b *backendExecutionResults) GetExecutionResultByID(ctx context.Context, id flow.Identifier) (*flow.ExecutionResult, error) {

Suggestion:

Unfortunately, I have to recommend to copy the "caution"-block into the implementations of all methods of the Access API interface
- Though, I would only add this doc to the method implementations in package engine/access/rpc/backend for example, because here we are interfacing with the protocol-layer code that might throw irrecoverable or unclassified fatal errors.
- Yet, another implementation of GetExecutionResultByID exists in the engine/access/rest/apiproxy package. This code does not interface with protocol-level components. Since that is pretty clear from context, I would suggest to not invest the time adding "caution"-blocks to the Access API implementations here. Neither do I think that the corresponding functions in the engine/access/rest/http/routes package require explicitly documentation.
I hope these examples help to clarify where I think extra documentation would be beneficial vs where not.

Sorry, that this is boring work .. hopefully doesn't take long. I think the time is well-spent future-proofing the codebase by cleanly documenting the boundary where the error-handling convention changes.

AlexHentschel · 2025-03-15T03:45:43Z

engine/access/rpc/backend/backend.go

+// No errors are expected during normal operation.
+// All errors can be considered benign. Exceptions are handled explicitly within the backend and are
+// not propagated.


Suggested change

// No errors are expected during normal operation.

// All errors can be considered benign. Exceptions are handled explicitly within the backend and are

// not propagated.

//

// CAUTION: this layer SIMPLIFIES the ERROR HANDLING convention

// As documented in the [access.API], which we partially implement with this function

// - All errors returned by this API are guaranteed to be benign. The node can continue normal operations after such errors.

// - Hence, we MUST check here and crash on all errors *except* for those known to be benign in the present context!

AlexHentschel · 2025-03-15T03:45:54Z

engine/access/rpc/backend/backend.go

+// No errors are expected during normal operation.
+// All errors can be considered benign. Exceptions are handled explicitly within the backend and are
+// not propagated.


Suggested change

// No errors are expected during normal operation.

// All errors can be considered benign. Exceptions are handled explicitly within the backend and are

// not propagated.

//

// CAUTION: this layer SIMPLIFIES the ERROR HANDLING convention

// As documented in the [access.API], which we partially implement with this function

// - All errors returned by this API are guaranteed to be benign. The node can continue normal operations after such errors.

// - Hence, we MUST check here and crash on all errors *except* for those known to be benign in the present context!

AlexHentschel · 2025-03-15T03:47:42Z

engine/access/rpc/backend/backend.go

+// Expected errors:
+// - access.DataNotFoundError if the collection is not found.
+//
+// All errors can be considered benign. Exceptions are handled explicitly within the backend and are
+// not propagated.


Suggested change

// Expected errors:

// - access.DataNotFoundError if the collection is not found.

//

// All errors can be considered benign. Exceptions are handled explicitly within the backend and are

// not propagated.

// CAUTION: this layer SIMPLIFIES the ERROR HANDLING convention

// As documented in the [access.API], which we partially implement with this function

// - All errors returned by this API are guaranteed to be benign. The node can continue normal operations after such errors.

// - Hence, we MUST check here and crash on all errors *except* for those known to be benign in the present context!

//

// Expected sentinel errors providing details to clients about failed requests:

// - access.DataNotFoundError if the collection is not found.

AlexHentschel · 2025-03-15T03:48:17Z

engine/access/rpc/backend/backend.go

+// Expected errors:
+// - access.DataNotFoundError if the collection is not found.
+//
+// All errors can be considered benign. Exceptions are handled explicitly within the backend and are
+// not propagated.


Suggested change

// Expected errors:

// - access.DataNotFoundError if the collection is not found.

//

// All errors can be considered benign. Exceptions are handled explicitly within the backend and are

// not propagated.

// CAUTION: this layer SIMPLIFIES the ERROR HANDLING convention

// As documented in the [access.API], which we partially implement with this function

// - All errors returned by this API are guaranteed to be benign. The node can continue normal operations after such errors.

// - Hence, we MUST check here and crash on all errors *except* for those known to be benign in the present context!

//

// Expected sentinel errors providing details to clients about failed requests:

// - access.DataNotFoundError if the collection is not found.

AlexHentschel · 2025-03-15T03:51:43Z

engine/access/rpc/backend/backend.go

-) error {
-	if !errors.Is(genericErr, storage.ErrNotFound) {
-		return genericErr
+// Will return the original error, possibly wrapped with additional context.


❓⚠️❓ I am wondering if we need to consider the next layer of code here

Please confirm that my understanding here is correct:

Suggested change

// Will return the original error, possibly wrapped with additional context.

// Will return the original error, possibly wrapped with additional context.

// CAUTION: this function might return irrecoverable errors or generic fatal from the lower protocol layers

Lets take a look at a couple of places that are calling resolveHeightError:

flow-go/engine/access/rpc/backend/backend_accounts.go

Lines 64 to 72 in 95bbc46

// GetAccountAtBlockHeight returns the account details at the given block height.

func (b *backendAccounts) GetAccountAtBlockHeight(

ctx context.Context,

address flow.Address,

height uint64,

) (*flow.Account, error) {

blockID, err := b.headers.BlockIDByHeight(height)

if err != nil {

return nil, rpc.ConvertStorageError(resolveHeightError(b.state.Params(), height, err))

We are calling into protocol-level logic (line 70), which might return a generic exception or an irrecoverable error. As I understand it, resolveHeightError will just pass the error through; we'll wrap it as an Internal server error and return it to the client. To summarize: there was a fatal error and we have not recognized it as such.

Instead, I think lines 70-73 in GetAccountAtBlockHeight should read:

blockID, err := b.headers.BlockIDByHeight(height) if err != nil { err = access.RequireErrorIs(ctx, err, storage.ErrNotFound) // fatal for any error other than storage.ErrNotFound return nil, rpc.ConvertStorageError(resolveHeightError(b.state.Params(), height, err)) }

analogous change requests I have for functions

GetAccountBalanceAtBlockHeight

GetAccountKeyAtBlockHeight

GetAccountKeysAtBlockHeight

GetBlockByHeight

GetBlockHeaderByHeight

GetEventsForHeightRange. In this function, I noticed additional places where we call into the protocol logic:

flow-go/engine/access/rpc/backend/backend_events.go

Lines 70 to 77 in 95bbc46

// get the latest sealed block header

sealed, err := b.state.Sealed().Head()

if err != nil {

// sealed block must be in the store, so throw an exception for any error

err := irrecoverable.NewExceptionf("failed to lookup sealed header: %w", err)

irrecoverable.Throw(ctx, err)

return nil, err

}

but I am not convinced that irrecoverable errors or unexpected exceptions lead to node termination.

ExecuteScriptAtBlockHeight

Essentially, I am worried about any place you are calling into the low-level protocol. For all of those method, I would suggest to include the "caution"-goDoc-block as in my comment above and crash on any error except the expected error.

For getAccountFromLocalStorage I am less sure, because I am not sure how rigorous the execution team is doing their error handling.

AlexHentschel · 2025-03-15T04:20:54Z

engine/access/rpc/backend/backend_execution_results.go

for functions in this file, I would suggest to include the "caution"-block in their goDocs:

// CAUTION: this layer SIMPLIFIES the ERROR HANDLING convention // As documented in the [access.API], which we partially implement with this function // - All errors returned by this API are guaranteed to be benign. The node can continue normal operations after such errors. // - Hence, we MUST check here and crash on all errors *except* for those known to be benign in the present context!

AlexHentschel · 2025-03-15T04:22:47Z

engine/access/rpc/backend/backend_network.go

+// No errors are expected during normal operation.
+// All errors can be considered benign. Exceptions are handled explicitly within the backend and are
+// not propagated.


Suggested change

// No errors are expected during normal operation.

// All errors can be considered benign. Exceptions are handled explicitly within the backend and are

// not propagated.

// CAUTION: this layer SIMPLIFIES the ERROR HANDLING convention

// As documented in the [access.API], which we partially implement with this function

// - All errors returned by this API are guaranteed to be benign. The node can continue normal operations after such errors.

// - Hence, we MUST check here and crash on all errors *except* for those known to be benign in the present context!

AlexHentschel · 2025-03-15T04:23:12Z

engine/access/rpc/backend/backend_network.go

+// All errors can be considered benign. Exceptions are handled explicitly within the backend and are
+// not propagated.
+//
+// The block may or may not be finalized in the future; the client can retry later.


Suggested change

// All errors can be considered benign. Exceptions are handled explicitly within the backend and are

// not propagated.

//

// The block may or may not be finalized in the future; the client can retry later.

// CAUTION: this layer SIMPLIFIES the ERROR HANDLING convention

// As documented in the [access.API], which we partially implement with this function

// - All errors returned by this API are guaranteed to be benign. The node can continue normal operations after such errors.

// - Hence, we MUST check here and crash on all errors *except* for those known to be benign in the present context!

AlexHentschel · 2025-03-15T04:23:37Z

engine/access/rpc/backend/backend_network.go

 	}

 	return data, nil
 }

 // GetProtocolStateSnapshotByBlockID returns serializable Snapshot for a block, by blockID.
 // The requested block must be finalized, otherwise an error is returned.
+//
 // Expected errors during normal operation:


Suggested change

// Expected errors during normal operation:

// Dedicated sentinel errors providing details to clients about failed requests:

AlexHentschel · 2025-03-15T04:24:07Z

engine/access/rpc/backend/backend_network.go

 	}
 	return data, nil
 }

 // GetProtocolStateSnapshotByHeight returns serializable Snapshot by block height.
 // The block must be finalized (otherwise the by-height query is ambiguous).
+//
 // Expected errors during normal operation:


Suggested change

// Expected errors during normal operation:

// Dedicated sentinel errors providing details to clients about failed requests:

AlexHentschel · 2025-03-15T04:37:13Z

engine/access/rpc/backend/backend_network.go

 	snapshot := b.state.Final()
 	data, err := convert.SnapshotToBytes(snapshot)
 	if err != nil {
-		return nil, status.Errorf(codes.Internal, "failed to convert snapshot to bytes: %v", err)
+		return nil, access.RequireNoError(ctx, fmt.Errorf("failed to convert snapshot to bytes: %w", err))


I think at the moment, we do not guarantee that a snapshot can always be constructed for any finalized block (in other words, I think this call can fail

Suggested change

return nil, access.RequireNoError(ctx, fmt.Errorf("failed to convert snapshot to bytes: %w", err))

err = access.RequireErrorIs(ctx, err, protocol.ErrSealingSegmentBelowRootBlock, protocol.NewUnfinalizedSealingSegmentErrorf(""))

return nil, fmt.Errorf("snapshots might not be possible for every block: %w", err)

I think @jordanschalm knows if we would always be able to generate a snapshot for any block (including the root block when the node is freshly bootstrapped). Only if that is the case, we can use access.RequireNoError here .

AlexHentschel · 2025-03-15T04:41:07Z

engine/access/rpc/backend/backend_network.go

+		// The block exists, but no block has been finalized at its height. Therefore, this block
+		// may be finalized in the future, and the client can retry.
+		return nil, access.NewPreconditionFailedError(
+			fmt.Errorf("failed to retrieve snapshot for block with height %d: block not finalized and is above finalized height",


Suggested change

fmt.Errorf("failed to retrieve snapshot for block with height %d: block not finalized and is above finalized height",

fmt.Errorf("failed to retrieve snapshot: block still pending finalization",

AlexHentschel · 2025-03-15T04:41:25Z

engine/access/rpc/backend/backend_network.go

+		// storage.ErrNotFound is specifically NOT allowed since the snapshot's reference block must exist
+		// within the snapshot.
+		err = access.RequireErrorIs(ctx, err, state.ErrUnknownSnapshotReference)
+		return nil, access.NewDataNotFoundError("snapshot", fmt.Errorf("failed to retrieve a valid snapshot: block not found"))


Suggested change

return nil, access.NewDataNotFoundError("snapshot", fmt.Errorf("failed to retrieve a valid snapshot: block not found"))

return nil, access.NewDataNotFoundError("snapshot", fmt.Errorf("failed to retrieve snapshot: block not found"))

AlexHentschel · 2025-03-15T04:42:43Z

engine/access/rpc/backend/backend_network.go

 	}

 	if blockIDFinalizedAtHeight != blockID {
 		// A different block than what was queried has been finalized at this height.
 		// Therefore, the queried block will never be finalized.
-		return nil, status.Errorf(codes.InvalidArgument,
-			"failed to retrieve snapshot for block: block not finalized and is below finalized height")
+		return nil, access.NewInvalidRequestError(fmt.Errorf("failed to retrieve snapshot for block: block not finalized and is below finalized height"))


Suggested change

return nil, access.NewInvalidRequestError(fmt.Errorf("failed to retrieve snapshot for block: block not finalized and is below finalized height"))

return nil, access.NewInvalidRequestError(fmt.Errorf("failed to retrieve snapshot: block orphaned"))

AlexHentschel · 2025-03-15T04:46:19Z

engine/access/rpc/backend/backend_network.go

 	}

 	data, err := convert.SnapshotToBytes(snapshot)
 	if err != nil {
-		return nil, status.Errorf(codes.Internal, "failed to convert snapshot to bytes: %v", err)
+		return nil, access.RequireNoError(ctx, fmt.Errorf("failed to convert snapshot to bytes: %w", err))


Only if we can guarantee that we are always be able to generate a snapshot for any block (including the root block when the node is freshly bootstrapped) we can use access.RequireNoError here (same as comment above)

Suggested change

return nil, access.RequireNoError(ctx, fmt.Errorf("failed to convert snapshot to bytes: %w", err))

err = access.RequireErrorIs(ctx, err, protocol.ErrSealingSegmentBelowRootBlock, protocol.NewUnfinalizedSealingSegmentErrorf(""))

return nil, fmt.Errorf("snapshots might not be possible for every block: %w", err)

AlexHentschel

some more functions that I noticed probably needing handling of exceptions

AlexHentschel · 2025-03-15T04:49:01Z

engine/access/rpc/backend/backend_network.go

 	}

 	data, err := convert.SnapshotToBytes(snapshot)
 	if err != nil {
-		return nil, status.Errorf(codes.Internal, "failed to convert snapshot to bytes: %v", err)
+		return nil, access.RequireNoError(ctx, fmt.Errorf("failed to convert snapshot to bytes: %w", err))


Only if we can guarantee that we are always be able to generate a snapshot for any block (including the root block when the node is freshly bootstrapped) we can use access.RequireNoError here (same as comment above)

Suggested change

return nil, access.RequireNoError(ctx, fmt.Errorf("failed to convert snapshot to bytes: %w", err))

err = access.RequireErrorIs(ctx, err, protocol.ErrSealingSegmentBelowRootBlock, protocol.NewUnfinalizedSealingSegmentErrorf(""))

return nil, fmt.Errorf("snapshots might not be possible for every block: %w", err)

AlexHentschel · 2025-03-15T04:57:32Z

engine/access/rpc/backend/backend_transactions.go

we only interact with a single protocol-level component here:

flow-go/engine/access/rpc/backend/backend_transactions.go

Line 35 in e176fe3

transactions storage.Transactions

in addition to TransactionsLocalDataProvider, which I commented on below

AlexHentschel · 2025-03-15T04:58:57Z

engine/access/rpc/handler.go

not using any protocol components, so its probably fine as is (?)

AlexHentschel · 2025-03-15T05:03:17Z

engine/access/rpc/backend/transactions_local_data_provider.go

errors returned by these protocol components should ideally be checked for unexpected exceptions:

flow-go/engine/access/rpc/backend/transactions_local_data_provider.go

Lines 48 to 50 in e176fe3

state protocol.State

collections storage.Collections

blocks storage.Blocks

in many cases, we just convert an exception and send a message to the client, e.g.

flow-go/engine/access/rpc/backend/backend_transactions.go

Line 451 in e176fe3

return nil, rpc.ConvertStorageError(err)

AlexHentschel · 2025-03-15T05:06:49Z

engine/common/rpc/execution_node_identities_provider.go

this is another component, where we ideally would like to check errors returned by these lower-level protocol components 👇

flow-go/engine/common/rpc/execution_node_identities_provider.go

Lines 30 to 31 in e176fe3

executionReceipts storage.ExecutionReceipts

state protocol.State

and crash in case of unexpected exceptions

AlexHentschel

from Yurii's comment

clearly documented and defined somewhere.

eventually each function from "backend" that implements some endpoint must include RequireNoError/RequireErrorIs/RequireAccessError, this way we ensure that only benign errors are propagated to the caller.

Most of my comments are aimed at achieving this. Though, my comments are likely not an exhaustive list of all places where such error checks should be added.

add initial error framework

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.

GPG key ID: 4AEE18F83AFDEB23
Expired

Verified
Learn about vigilant mode

e176fe3

peterargue requested a review from a team as a code owner February 28, 2025 20:43

peterargue added 2 commits February 28, 2025 12:45

rename rest error converter

049bc5f

improve comments in network endpoints

e4c2ea3

peterargue commented Feb 28, 2025

View reviewed changes

peterargue added 4 commits March 3, 2025 09:46

add catchall error declaration

e4a33d9

update error handling comments

4a7ba95

improve error converter godocs

f99e889

add require access error

e269179

peterargue commented Mar 4, 2025

View reviewed changes

durkmurder approved these changes Mar 5, 2025

View reviewed changes

engine/access/rpc/backend/backend_network.go Outdated Show resolved Hide resolved

engine/access/rpc/backend/backend_network.go Outdated Show resolved Hide resolved

engine/access/rpc/backend/backend_network.go Outdated Show resolved Hide resolved

throw exception if converting snapshot fails

6b039eb

fix error names and add sentinels for ctx errors

df07206

AlexHentschel reviewed Mar 15, 2025

View reviewed changes

AlexHentschel approved these changes Mar 15, 2025

View reviewed changes

AlexHentschel reviewed Mar 15, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Access] Add draft of access api error framework #7106

[Access] Add draft of access api error framework #7106

peterargue commented Feb 28, 2025 •

edited

Loading

peterargue Feb 28, 2025 •

edited

Loading

peterargue Feb 28, 2025 •

edited

Loading

peterargue Feb 28, 2025

peterargue Mar 4, 2025

AlexHentschel Mar 15, 2025

durkmurder left a comment

peterargue commented Mar 5, 2025

AlexHentschel left a comment

AlexHentschel Mar 15, 2025

AlexHentschel left a comment •

edited

Loading

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025 •

edited

Loading

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025 •

edited

Loading

AlexHentschel left a comment

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025 •

edited

Loading

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel Mar 15, 2025

AlexHentschel left a comment •

edited

Loading

	// This is a more specific version of DataNotFoundError, where the data is known to eventually exist, but
	// currently is not known.

	// GetExecutionResultByID gets an execution result by its ID.
	func (b backendExecutionResults) GetExecutionResultByID(ctx context.Context, id flow.Identifier) (flow.ExecutionResult, error) {

	// Will return the original error, possibly wrapped with additional context.
	// Will return the original error, possibly wrapped with additional context.
	// CAUTION: this function might return irrecoverable errors or generic fatal from the lower protocol layers

	// GetAccountAtBlockHeight returns the account details at the given block height.
	func (b *backendAccounts) GetAccountAtBlockHeight(
	ctx context.Context,
	address flow.Address,
	height uint64,
	) (*flow.Account, error) {
	blockID, err := b.headers.BlockIDByHeight(height)
	if err != nil {
	return nil, rpc.ConvertStorageError(resolveHeightError(b.state.Params(), height, err))

	// get the latest sealed block header
	sealed, err := b.state.Sealed().Head()
	if err != nil {
	// sealed block must be in the store, so throw an exception for any error
	err := irrecoverable.NewExceptionf("failed to lookup sealed header: %w", err)
	irrecoverable.Throw(ctx, err)
	return nil, err
	}

	// Expected errors during normal operation:
	// Dedicated sentinel errors providing details to clients about failed requests:

	return nil, access.RequireNoError(ctx, fmt.Errorf("failed to convert snapshot to bytes: %w", err))
	err = access.RequireErrorIs(ctx, err, protocol.ErrSealingSegmentBelowRootBlock, protocol.NewUnfinalizedSealingSegmentErrorf(""))
	return nil, fmt.Errorf("snapshots might not be possible for every block: %w", err)

	fmt.Errorf("failed to retrieve snapshot for block with height %d: block not finalized and is above finalized height",
	fmt.Errorf("failed to retrieve snapshot: block still pending finalization",

	return nil, access.NewDataNotFoundError("snapshot", fmt.Errorf("failed to retrieve a valid snapshot: block not found"))
	return nil, access.NewDataNotFoundError("snapshot", fmt.Errorf("failed to retrieve snapshot: block not found"))

	return nil, access.NewInvalidRequestError(fmt.Errorf("failed to retrieve snapshot for block: block not finalized and is below finalized height"))
	return nil, access.NewInvalidRequestError(fmt.Errorf("failed to retrieve snapshot: block orphaned"))

	state protocol.State
	collections storage.Collections
	blocks storage.Blocks

	executionReceipts storage.ExecutionReceipts
	state protocol.State

[Access] Add draft of access api error framework #7106

Are you sure you want to change the base?

[Access] Add draft of access api error framework #7106

Conversation

peterargue commented Feb 28, 2025 • edited Loading

peterargue Feb 28, 2025 • edited Loading

Choose a reason for hiding this comment

peterargue Feb 28, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

durkmurder left a comment

Choose a reason for hiding this comment

peterargue commented Mar 5, 2025

AlexHentschel left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlexHentschel left a comment • edited Loading

Choose a reason for hiding this comment

Suggestion:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlexHentschel Mar 15, 2025 • edited Loading

Choose a reason for hiding this comment

❓⚠️❓ I am wondering if we need to consider the next layer of code here

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlexHentschel Mar 15, 2025 • edited Loading

Choose a reason for hiding this comment

AlexHentschel left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlexHentschel Mar 15, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlexHentschel left a comment • edited Loading

Choose a reason for hiding this comment

peterargue commented Feb 28, 2025 •

edited

Loading

peterargue Feb 28, 2025 •

edited

Loading

peterargue Feb 28, 2025 •

edited

Loading

AlexHentschel left a comment •

edited

Loading

AlexHentschel Mar 15, 2025 •

edited

Loading

AlexHentschel Mar 15, 2025 •

edited

Loading

AlexHentschel Mar 15, 2025 •

edited

Loading

AlexHentschel left a comment •

edited

Loading