Support increased retry + caching when getting a transactions status

[JeffreyDoyle]

Issue to be solved

Today, Flow's public ANs sit behind a load balancer that round-robins requests to it to the access nodes it sits in front of. When a transaction is submitted to the network, it is forwarded from the load balancer to one of the access nodes and then sent into the Flow network for execution.

Subsequent requests to the public ANs to query for the status of that transaction are then sent to other access nodes, which might not yet know about the transaction as it has not yet been propagated among the network and therefore visible to them. These requests can fail, with the access nodes returning a 404 response since they don't yet know of the transaction.

This presents an issue for clients such as FCL, as some requests to the public ANs will successfully return a transaction status, and others will return a 404 error.

The solution for this problem is both to ensure Flow's access node infrastructure is updated to avoid this issue and also to update FCL to be more resilient to this issue.

Solution

We should update FCL to:

• Increase the retry count for GetTransactionStatus interactions to a greater number.
• Cache successful responses when getting a transaction's status, and return those if/when subsequent requests return 404.

[bluesign]

I suggested this before but polling for transaction result is not really efficient way to do this. I would suggest adding transaction result subscription to streaming API, then FCL can query this easily. ( plus we can add callback based new transaction result API )