The Access API should return the block status for all GetBlockXXX calls

[vishalchangrani]

Problem Definition

What problem is this solving?

After a spork, the old network can continue to report finalized blocks with the same block height as the starting blocks of the new network.

e.g.

mainnet18 : A (last sealed) <- B (35858811) <- C <- D (last finalized) <- E <- F <- G
mainnet19 :                 ^- H (root block) <- I <- J

This is a source of confusion for clients that are consuming blocks from the old network before switching over to the network as reported here

Proposed Solution

What are the proposed solutions to this problem?

The solution is to report the Block status (finalized, executed, sealed) as part of the block response for all Block related Get queries that the access node responds to. This applies to both the gRPC API and the REST API.

Definition of Done

What tests must pass for this issue to be considered solved?

All Block related responses (gRPC and REST) must carry the block status.

Actions Needed Before Submitting

Update ticket status using the following (remove this section once ticket created)

• What workstream does this ticket deal with? Find the appropriate 'S-' label and add that label.
• Is it a specific 'type' of ticket (ex: bug, documentation)? If yes, add that label as well.
• Is this ticket related to an overarching theme (ex: architecture, performance)? If yes, add that label as well.
• Add any/all descriptive characteristic labels needed (ex: Needs Estimation, Needs Test Cases).
• Now we should determine what release this ticket is associated with. If none, leave it blank. If it is associated with a specific release, please add it to the appropriate release.
• If this ticket is associated with a release, we want to assign it a level of importance within that release. These labels follow the standard MoSCoW method rules. We want to look at releases and then the importance of tickets within those specific releases. So the MoSCoW label is ONLY valid when it is taken in conjunction with its release.
• Assign this ticket a priority level (High, Medium, Low) via the appropriate label. These labels control the importance of the ticket within the sprint. For example, all P-High tickets should be worked on first, then P-Medium, then P-Low. This gives us an easy way to identify the order of priority for tickets within a specific sprint.

Simiar issue on Flow-cli

[lolpuddle]

Proposed Implementations

• Updating the definition of Flow.Block to include the status states. This would be a sweeping change that would touch a large amount of the flow-go codebase, and status won't always be available as knowledge of state is not implicit.

or

• Stitching together TransactionStatus into our GetBlock APIs by adding a GetTransactionResultsByBlockID call as part of the process of querying for blocks to get that necessary status data

This is in response to vishal's proposed solution of adding status to the queries

Any thoughts, or alternatives? @vishalchangrani @Kay-Zee