Handle eth tx canceled/ speed up / replaced

[paouvrard]

From metamask a user may speed up an approve or lock transaction. Since the dapp frontend has no knowledge of this, it will keep checking the status of a transaction which has already been replaced and will never be mined. This is common behavior on eth mainnet especially with recent gas price variations. For dapps like uniswap this is not an issue as nothing depends on the execution result of the swap. But for the bridge:

• If this happens on an approve tx, the user will never be able to create another transfer to Near due to the double approval override safety
• If this happens on a lock tx, the dapp frontend will keep waiting for that lock tx and never be able to build a lock proof to mint the tokens on Near.

Discussions on the topic:
web3/web3.js#3585
web3/web3.js#3723
https://eips.ethereum.org/EIPS/eip-2831

Also there doesn't seem to be a good way to check transaction statuses with the account nonce since that would require an indexing service such as etherscan.

cc @djsatok

[paouvrard]

Possible solution: add an input field (troubleshooting menu?) where given an eth or near transaction hash, the frontend will check the nature of that transaction (eth lock or near withdraw) and create a new pending transfer object entry to be finalized.

This would also be useful should any transfer get stuck due to a UI bug, user deleting storage, user changing browser or not having access to the transfers in local storage for any reason. Users can then make sure that transfer finalize without requiring out assistance or looking through localStorage. And combined with a delete button to cleanup the transfer history.

[paouvrard]

[heycorwin]

@djsatok @paouvrard what happens to the original txn in this scenario? Does it just persist indefinitely? Is there a way for us to indicate on the original txn that it is no longer valid?

I will be proposing some UX changes in response to the above.

[alexauroradev]

I do believe that we need to give an ability for a user to delete transfer from the list, if we're implementing add transfer to the list.
In terms of the UX, I feel we just should add small x in the top right (or left) corner, which is deletion button. In case the transfer is in progress (waiting or requiring the user input), there should be a warning displayed that a user wants to delete not-finalised transfer.
@corwinharrell

[heycorwin]

@djsatok @paouvrard I think it's fine to explore a way to offer the user the ability to delete an existing TXN. However my original question still stands:

In it's current state, what happens to a TXN that becomes "stuck"? Is there any way for the UI to indicate to the user that this has occured (ie a visual indication)? Is it up to the user to figure out that a particular TXN has been affected by an update via Metamask?

This is important because it's quite a poor UX to not have any way whatsoever to indicate that a specific TXN requires special attention. I mentioned this at the start of the project when we designed the alerts/toasts that never made it into the UI, but it's important for us to have some way to communicate to the user when certain actions require their attention.

It's not sufficient for the UI to expect the user to have their eyes glued to the list of TXNs waiting to observe a change. If a TXN becomes stuck, or a TXN changes state and requires input from the user to advance, we should have a way to alert/notify the user beyond just changing the color of the TXN card. For a UI that is built entirely around the idea of TXN moving through various states over time (and sometimes a significant time period), I view this as a critical component.

Thoughts?

[heycorwin]

Some additional context after something I noticed. In the original designs, there was an additional tab above the transfer list labelled Requires attention. The intent here was to move all transfers that required input from the user in order to advance to this tab. Chad made the decision to remove this tab in hopes that the alerts/toasts would be sufficient for notifying the user that a particular transaction required their attention. Since the alerts/toast were never implemented, we now have no way of calling attention to the transfers that require user input in order to advance. My proposal is that until we have a better system in place for notifying the user about important activity, we re-introduce this tab, so that all transfers that require user input get relocated here. This way, there is at minimum a subtle way to us to indicate that certain transfers require user input:

[heycorwin]

@djsatok @paouvrard Here are my proposed changes. These are also visible in the project Figma doc.

1. Improved UX/flow for restoring a transaction: As per @djsatok's suggestion, I've made sure to include messaging warning the user that this feature should only be used for in-flight transfers. Feel free to tweak the language here, although we will want to keep it clear and concise.
2. Addition of Requires attention tab in the transfers list: As outlined above, until we have the capacity to implement alerts/notifications in order to draw the user's attention to transfers that require their input in order to advance, we can do so in a more low-lift/subtle manner by moving any transfers that require action to this tab. Once the user performs the necessary action, the transfer will move back to Processing or Complete.

3. Ability to delete transfers: Again as per @djsatok's suggestion, I've now added a button with a trashcan icon to allow users to delete transfers that are either processing or have failed. In addition, I've designed a modal to display to the user in order to require a confirmation that this is an action they wish to perform, outlining the risk.

@djsatok if you have any additional feedback per our conversation just let me know.

[paouvrard]

From a twitter thread yesterday, detection of tx canceled/speedup can be done with:
https://twitter.com/ricmoo/status/1371700667920842756?s=21

"I check the "latest" transactionCount on each block, if it changes without the tx hash being mined, fetch that block (with transactions) to find the matching from+nonce. If the to+data matches, its a replacement, otherwise it’s a cancel. I’m adding this to ethers-app. :)"

This is not a replacement for the recovery feature, but a much better user experience to handle these cases automatically

[alexauroradev]

@paouvrard, you can document this logic as a feature request for future

[paouvrard]

Implemented here: aurora-is-near/rainbow-bridge-client#15