Transactions squeezed out in-between submit and statusChange calls hang indefinitely

[nedsalk]

@Torres-ssf did tests on devnet and found that sending a transaction would sometimes hang indefinitely. After some investigation, the problem was found to be transactions being squeezed out after submitting them but before a statusChange subscription is established. This statusChange subscription would then hang indefinitely because the squeezed out transaction is unavailable on the node.

Solution

To solve this, we'd have to use the submitAndAwait endpoint instead of submit in Provider.sendTransaction. This way the SqueezedOutStatus status wouldn't be lost as it'd be sent as the second event on the subscription after SubmittedStatus.

There are other considerations here. For example, what happens if we submit the transaction and the connection breaks? We'd have to use the statusChange subscription then, but we'd be back on square one because the transaction can be squeezed out in the meantime. That would require some internal "squeezed out timer" on statusChange which'd throw an error if there's no response from the node after e.g. 20 seconds, and this error would be something like "The transaction was probably squeezed out". This can be a separate issue.

Another thing worthy of covering is that a node has a maximum active subscriptions limit. What happens when that limit is reached and how do we account for that?

[nedsalk]

Blocked by:

• Make submitAndAwait errors immediately identifiable fuel-core#2108

Work has already been done on this issue and exists on the branch ns/feat/submit-and-await.

[maschad]

FuelLabs/fuel-core#2120 has been merged so this is no longer blocked

EDIT: Work can continue on a PR but we can't merge this until it's released in a fuel-core version post-v0.34.0