Handling errors

[lrettig]

When a client queries a full node for a piece of data - say, a transaction receipt - there is a difference between the node thinking the ID of the data that was asked for is invalid (i.e., "this ID does not match any transaction I know of"), vs. the node thinking the ID is valid, but not having access to the data right now ("this transaction ID looks valid, but I may have pruned this data and no longer have it"). In the former case, the client can probably give up looking for the data; in the latter case, they could try asking someone else for it, or perhaps an archive node.

Do we want to attempt to distinguish between these cases in the API?

[avive]

Related: https://grpc.io/docs/guides/error/

[lrettig]

Thanks. It does look like GRPC and protobuf has support for a fairly rich error system, including metadata. I don't think we'll have trouble implementing whatever we decide we need here - what I proposed/asked above is really quite straightforward. Having multiple error types should fit the bill - sort of like HTTP status codes, 404 not found ("I've never heard of this ID before)" vs. something like 301/302/307 ("the ID looks valid but the data lives elsewhere").

[lrettig]

Here's a starting list (continuing to model on the HTTP codes, for now):

• 200: OK: Here's the data you asked for
• 301: Moved Permanently: I don't have this data, try this other URI; if you ask again, use the other URI
• 307: Moved Temporarily: I don't have this data right now, but I might have it again later; use this other URI; if you ask again, you can try asking me again
• 306: Unavailable: I used to have this data, but now I don't, and I don't know where you might find it
• 404: I've never heard of this data before

What am I missing?

[lrettig]

I ended up using these GRPC error codes, which I think make more sense than HTTP error codes. A few other questions have come up related to error handling during the implementation, including:

• Is it a user error or an internal error if an API call asks for a layer higher than the current layer? What about one less than the current layer, but one that a node does not know about? (API phase 7: MeshService go-spacemesh#2059 (review))