Get Block endpoint is missing the system collection

[janezpodhostnik]

Problem Definition

Getting transactions by block ID is complicated because the block collection guarantees do not contain the system chunk. Because of this the system transaction needs to be fetched individually by a separate method.

The access node does some weird gymnastics to get around this issue:

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

  Line 477 in d9ae9eb

  systemTx, err := blueprints.SystemChunkTransaction(b.chainID.Chain())

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

  Line 227 in d9ae9eb

  systemTx, err := blueprints.SystemChunkTransaction(b.chainID.Chain())

And there is a proposed workaround in the CLI: onflow/flow-cli#1123

Ideally there wouldn't need to be workarounds to add the system transaction to get transactions by block results.

Proposed Solution

Definition of Done

We need a generalised way to fetch all transactions in a block (including the system transaction)

[peterargue]

@janezpodhostnik you're definitely right that the system tx/collection are missing and a bit confusing in the Access API today. Reading over this issue, I'm not totally clear on what the goal is. I think we could add support for querying the system transaction/result fairly easily since the TX IDs are static and known.

I think it would be less straight forward to add the system collection ID into the block response or add support for querying the system collection by ID. I'm not actually sure if it's even static. Currently, we return and empty collectionID since we don't locally index it.

[janezpodhostnik]

since the TX IDs are static and known

I would like t o avoid relying on this. Its not guaranteed it will stay static forever, and I wouldn't want to break any code when/if we make it non-static.

I'm not exactly sure what to do here, but I would definitely want to avoid the CLI or the SDKs needing to solve this issue.

[peterargue]

since the TX IDs are static and known

I would like t o avoid relying on this. Its not guaranteed it will stay static forever, and I wouldn't want to break any code when/if we make it non-static.

I'm not exactly sure what to do here, but I would definitely want to avoid the CLI or the SDKs needing to solve this issue.

That's fair.

I think we should definitely add new endpoints for getting the system tx directly for a block. Something like GetSystemTransaction and GetSystemTransactionResult which required a blockID.

We may also want to add support in GetTransactionByIndex and GetTransactionResultByIndex to simplify iterating over the tx in a block. It's possible this works today.

We could add support to GetTransaction and GetTransactionResult, but I'm not convinced it's a good idea since system tx would require the blockID while others do not, making the API messier.

[bjartek]

since the TX IDs are static and known

I would like t o avoid relying on this. Its not guaranteed it will stay static forever, and I wouldn't want to break any code when/if we make it non-static.

I'm not exactly sure what to do here, but I would definitely want to avoid the CLI or the SDKs needing to solve this issue.

It is not static, it has been several values already, every time something new is added to it the hash change so it will change. Here are the values it has been historically:

b4fc3d14db4df4040e530f63d9debbecab0a587e20a039320e286d42261522e5
63c9898524de83c738015d0db8f50bab27e01e2edb5c7e19db7e2d80517a676c
5d4189f723905c2e777639af5d5058c1990c5f671d6200fc5e404a4ec1bed410
f31815934bff124e332b3c8be5e1c7a949532707251a9f2f81def8cc9f3d1458
41e8672b3ecb08bf91c6dc430fa6bd8af1e5a43547efdb59dc1814eeca278480