Swap marked as dropped but it was successful

[jagodarybacka]

Swapped on Optimism, CRV -> AAVE
https://optimistic.etherscan.io/tx/0xf5abee267fe5e4940b574ccd08ea0bf91bd8ec45b48a01afb70036a3fb8e673e

[jagodarybacka]

another one: in-wallet approval on Polygon

[tallysam]

this is difficult to reproduce.

[andreachapman]

I've also experienced this issue where Taho is reporting that the trxn was dropped but if you follow the scan link, it shows as successful. My latest example, with the evidence following, was not a swap though, it was a send.

Here's the trxn on the scan site and it says it was successful: https://snowtrace.io//tx/0x8f14e338a70e5f9bbd496778b1bda4400839bdce7ac2be42e2f55646d5f111e1

Here's a screenshot from the extension:

Here's a warning in console that corresponded to the time of the trxn:

And here's the log file I exported from the extension right after this happened (13:39 is the time):
DroppedTxnLogs2023-08-10T09_39_59-04_00.txt

[Shadowfiend]

What seems to be happening here is that after submission, we poll the remote node for our transaction and don't find it. Since we don't find it, we assume it was dropped—but we do that immediately, instead of retrying a handful of times or checking some other way.

I think part of the issue here is that eth_getTransaction is not pushed directly to Alchemy, while eth_send*Transaction calls are, which means that we won't check the node we submitted to—which should definitely have the transaction if it wasn't dropped—but instead we check a different node in the network. Since pending transactions can take time to propagate, and sometimes won't propagate at all until they're actually included in a block, we end up in trouble.

A couple of ways we can approach here:

• We can retry some number of times. Downside is we don't show transactions that actually were dropped as quickly; also, depending on how long the transaction takes to get confirmed, etc, we could still end up marking some as dropped.
• We can mark as dropped immediately, but continue to check dropped transactions that are the latest nonce periodically (e.g. with the regular transaction alarms) until there is a confirmed transaction with the same nonce OR we find that this “dropped” transaction was actually confirmed.
• We always use Alchemy for eth_getTransaction. Depending on how many of these calls we do, could get expensive.
• We always use Alchemy for these particular lookups (through some additional functionality in SerialFallbackProvider). I hate adding more functionality there though, that class is gnarly.
• If we fail to find it normally, we fall back on forcing Alchemy usage (again would require more code in SerialFallbackProvider).
• If we fail to find it normally, we do a direct Alchemy API call using their mempool stuff (either needs more code in SerialFallbackProvider or some separate mechanism that might not work for every chain).

The “continuing to check” approach seems most straightforward, as I think it's just a matter of adding an additional conditional before the cleanup at https://github.com/tahowallet/extension/blob/main/background/services/chain/index.ts#L1375-L1396 and re-enqueueing. If the nonce on the transaction is ahead of or same as the latest nonce, we don't stop querying for it. If the transaction is older than X (say 2 minutes or something), we mark it as dropped and release the nonce but continue querying. If we see a transaction with the same or greater nonce show up, we stop querying this transaction.