Clarify 'dropped' transaction

[Naxsun]

Discord Discussion Link

https://discord.com/channels/808358975287722045/944337346684391474/953214906092638238

What browsers are you seeing the problem on?

Chrome

What were you trying to do?

There's been quite some questions on what 'dropped' means and people using the Etherscan link with a non valid transaction.

What did not work?

Update the description of dropped to sometjing like 'dropped - not submitted' and remove Etherscan link

Version

Community Edition v0.12.1

Relevant log output

No response

[VladUXUI]

I wouldn't change the label in the activity page. Unless we can find a suitable one that is as short. But i would indeed remove the etherscan link and explain in the tx details page what dropped means.

Will require a little bit of design.

[VladUXUI]

This feels like a bit more work than this requires atm

[VladUXUI]

So maybe let's go with your suggested fix for now

[Naxsun]

I think this would help clarify a lot 👍

[Shadowfiend]

Transaction was not submitted

This isn't necessarily true. What dropped should mean is “we don't expect this will ever be confirmed on-chain”. This can be for a variety of reasons:

• The submission itself failed. Ideally a transaction that fails to submit actually doesn't make it into the list at all, but there are internal reasons this can play out differently at the moment.
• The submission succeeded, but the transaction had a low gas price and eventually was dropped from the mempool because of that.
• The submission succeeded, but the transaction was replaced by another transaction with the same nonce (either from Tally Ho or from a different wallet), either because it had a higher gas price or for some other reason.
• The submission succeeded, but the transaction had a nonce higher than the next nonce, and it was eventually purged from the mempool (this depends on the node that broadcast the transaction, and I'm not certain Alchemy behaves this way).
• A few other reasons I don't have off the top of my head 😅

All of these are valid reasons why a transaction would be dropped, and not all of them can have a more specific definition (e.g. “replaced” is reasonable if we know the transaction was replaced).

There's one more thing: because of the eventually-consistent nature of Ethereum especially, there is absolutely a version of events where a transaction is assumed to be dropped but actually becomes confirmed.

A bit more on dropped states from Etherscan @ https://info.etherscan.com/transaction-dropped-replaced/ .

[Naxsun]

I feel the main confusion for a user is currently around the first point.

"The submission itself failed. Ideally a transaction that fails to submit actually doesn't make it into the list at all, but there are internal reasons this can play out differently at the moment."

For the others there is a working Etherscan link that gives more details. As a quick win, are we able to recognize these easily and give these a different label? E.g. 'Failed to submit' or something similar?

[0xDaedalus]

Unclear what the path forward here is - as its not immediately obvious the best way to convey “we don't expect this will ever be confirmed on-chain”. to the user

[mhluongo]

I'd like to expand transaction history details beyond Vlad's design above to solve this. Happy to wireframe if it helps, but basically...

• Show when a tx request is created, and whether it came from a dApp, swap, or earn
• Show when it was signed, and where (local keyring, Ledger)
• Show when it was broadcast, and where (just Alchemy for now)
• Show if/when it was dropped from the mempool and why (replaced by nonce, gas too low, etc)

I also want to add "retry" and "rebroadcast" actions for these situations. In MM the closest you get is "Speed Up" which is frustrating.. you can't tell when it needs a signature but hasn't received one, eg from Ledger, or when it just needs to be broadcast.

[mhluongo]

I guess what I'm saying is... this feels like it deserves a real solution, not just a new label.

[Shadowfiend]

Probably deserves a clearer title + description if what you're describing is what this issue should embody; alternatively, we can spin up a new feature issue and close this with a reference to it.

[mhluongo]

Would be good to hear from @mr-michael — feels like this should be removed from the polish tracking ticket and get some longer product thought, or we should get a clear short-term solution here and I can open a new one with the other stuff.

[Naxsun]

"1. The submission itself failed. Ideally a transaction that fails to submit actually doesn't make it into the list at all, but there are internal reasons this can play out differently at the moment. 2. The submission succeeded, but the transaction had a low gas price and eventually was dropped from the mempool because of that. 3. The submission succeeded, but the transaction was replaced by another transaction with the same nonce (either from Tally Ho or from a different wallet), either because it had a higher gas price or for some other reason. 4. The submission succeeded, but the transaction had a nonce higher than the next nonce, and it was eventually purged from the mempool (this depends on the node that broadcast the transaction, and I'm not certain Alchemy behaves this way). 5. A few other reasons I don't have off the top of my head 😅"

The main confusion for the users related to this ticket were case 1, where the blockheight says 'pending' and the etherscan link isn't valid. They're expecting something still to happen.

From Antonio's list, I assume 2-4 should all have a valid Etherscan link?

If a short term solution could be: Having type 1 marked as 'failed to submit', without the status 'blockheight: pending' and without the Etherscan link --> this would solve the cause for this particular ticket imo.

fwiw, most of the cases of dropped transactions that I'm aware of were because the user tried to swap or send more than is possible when including the needed. For example sending or swapping using 'max ETH', setting up a transaction for the full ETH balance.

Once #858 / #1432 are implemented the occurrence rate of this should drop a lot.

[mr-michael]

or we should get a clear short-term solution here and I can open a new one with the other stuff.

@mhluongo I think this is the move. Let's fix ASAP but 100% on us needing/wanting a bigger fix here...perhaps a project for Gitcoin?

"1. The submission itself failed. Ideally a transaction that fails to submit actually doesn't make it into the list at all, but there are internal reasons this can play out differently at the moment. 2. The submission succeeded, but the transaction had a low gas price and eventually was dropped from the mempool because of that. 3. The submission succeeded, but the transaction was replaced by another transaction with the same nonce (either from Tally Ho or from a different wallet), either because it had a higher gas price or for some other reason. 4. The submission succeeded, but the transaction had a nonce higher than the next nonce, and it was eventually purged from the mempool (this depends on the node that broadcast the transaction, and I'm not certain Alchemy behaves this way). 5. A few other reasons I don't have off the top of my head 😅"

Quoting: @Naxsun:

"From Antonio's list, I assume 2-4 should all have a valid Etherscan link?"

@Shadowfiend is that correct?

"The main confusion for the users related to this ticket were case 1, where the blockheight says 'pending' and the etherscan link isn't valid. They're expecting something still to happen."

I'm aligned with @Naxsun here on this being the the place to intervene. Not sure what we can do here (or even what our txn states are tbh 🤦), but my vote would basically be to characterize this as "failed" (or at minimum remove the blockheight and etherscan link) if we are able to easily determine that this is simply never going to submit.

[Shadowfiend]

3 is the only one that's I'd feel good saying will show up on etherscan. Even then, it depends on whether replacement happened after the transaction propagated to etherscan's indexing nodes.

[Naxsun]

Based on some recent user feedback below would be my understanding.

• Case 1, a user gets 'Sorry, We are unable to locate this TxnHash': https://etherscan.io/tx/0x745965f6158fc53135b50f72385f67977f6062443acddac29c9cac09b5b77df4

There is no record of this transaction on Etherscan, it ever left the wallet?

• Case 2-4, --> there is a record for the transaction on Etherscan. It does not always show up the address accounts history, but there is data of the transaction itself tied to the transaction hash.

• Case 2 - does not show up on address transaction history, but the transaction hash page itself shows dropped and the transaction data.

• Case 3 - transactions show up on the address transaction history, multiple transactions with the same nonce with different status.

• Case 4 - does not show up on address transaction history, but the transaction hash page itself shows dropped and the tranaction data.

[henryboldi]

Bumping up some recent points,

If a short term solution could be: Having type 1 marked as 'failed to submit', without the status 'blockheight: pending' and without the Etherscan link --> this would solve the cause for this particular ticket imo.

Alignment

basically be to characterize this as "failed" (or at minimum remove the blockheight and etherscan link) if we are able to easily determine that this is simply never going to submit.

Type 1,

1. The submission itself failed. Ideally a transaction that fails to submit actually doesn't make it into the list at all, but there are internal reasons this can play out differently at the moment.

---

Because "a transaction that fails to submit actually doesn't make it into the list at all", will this short term solution make a real impact? I mean, in what case is a transaction failing to submit and making it into the list right now?

[Naxsun]

'in what case is a transaction failing to submit and making it into the list right now?'

For example if you have 0.1 ETH and swap or send 0.1 ETH.

It's listed as dropped in activity, and when opening the transaction details it'd have blockheight: pending

[Shadowfiend]

Not displaying the pending block height on dropped txes seems like an easy win.

An even easier one may be finding a way to fail those txes earlier--figuring out when we error and how to surface it as part of submission instead of after submission succeeds.

[henryboldi]

For example if you have 0.1 ETH and swap or send 0.1 ETH.

Should not be possible to do this again after https://github.com/tallycash/extension/pull/1689

Not displaying the pending block height on dropped txes seems like an easy win.

Adding https://github.com/tallycash/extension/issues/1817

figuring out when we error and how to surface it as part of submission instead of after submission succeeds.

So in other words, bring the errors to validation on the sign tx page? That sounds like a great UX idea too :)

[Shadowfiend]

Doing that requires active code on our end that will have to be set per chain. I'm talking about something a little simpler, which is ensuring that when we submit a transaction from the UI, if the backend node immediately fails it, the chain service and async thunk fail rather than pretending things worked and finding out they didn't later. This lets us at least give a minimum feedback that transaction submission failed right away, instead of pretending we broadcast it and then showing a dropped tx in the list.

EDIT: though to be clear, yes, validating as much as possible before the user hits sign/submit is absolutely the right end state.