hirosystems
Display and label transactions with dropped_stale_garbage_collect as "expired"
I clicked this link and initially it showed me the transaction history, but then I clicked again and it's showing a blank page: https://explorer.stacks.co/txid/0x839e9ef7f6ca2858e3d9e31bb057bee72b11f413e26f001b28287b91133079bc?chain=mainnet
Any ideas why that might happen?
I was just trying to see the tx history, but I did ask the user if they could provide additional context.
I think this is because it was not included in the main chain (the longest chain) which can happen sometimes. This transaction has therefore been 'dropped' https://stacks-node-api.mainnet.stacks.co/extended/v1/tx/0x839e9ef7f6ca2858e3d9e31bb057bee72b11f413e26f001b28287b91133079bc
Another one: https://explorer.stacks.co/txid/d602a022ede49ebe4ba8830dff0249e615a7ecd3f59a59649f422c84a0aa705a?chain=mainnet
I feel like we should address this by providing better feedback in the UI on this page? We handle a few tx_status states but don't currently catch tx_status: dropped_stale_garbage_collect. Tbh, I don't know a lot about what this means to make a suggestion. @zone117x what feedback can we provide the user in the explorer on these dropped transactions?
I think this is because it was not included in the main chain (the longest chain) which can happen sometimes. This transaction has therefore been 'dropped' https://stacks-node-api.mainnet.stacks.co/extended/v1/tx/0x839e9ef7f6ca2858e3d9e31bb057bee72b11f413e26f001b28287b91133079bc
I think we're conflating pending transactions that get dropped from the mempool after 256 blocks, with transactions that are confirmed but are not on the canonical fork. These are distinct issues.
All transactions in this issue are in the former category.
I clicked this link and initially it showed me the transaction history, but then I clicked again and it's showing a blank page: https://explorer.stacks.co/txid/0x839e9ef7f6ca2858e3d9e31bb057bee72b11f413e26f001b28287b91133079bc?chain=mainnet
Any ideas why that might happen?
This transaction had a bad nonce nonce of tx 839e9ef7f6ca2858e3d9e31bb057bee72b11f413e26f001b28287b91133079bc is 19 (expected 14) and was eventually dropped. User could have corrected the nonce gap.
Another one: https://explorer.stacks.co/txid/d602a022ede49ebe4ba8830dff0249e615a7ecd3f59a59649f422c84a0aa705a?chain=mainnet
This transaction just wasn't picked up due to other, more expensive contract calls in the mempool. User could have attempted RBF with higher fee.
Thanks for the explanation, this makes sense! Since we have the info from the api that the tx is 'dropped_stale_garbage_collect' we could very well display a better message than 'not found'. This should be an improvement , @andresgalante @markmhx I am adding this to the backlog.
To give some more context around tx_status: dropped_stale_garbage_collect, see:
https://github.com/blockstack/stacks-blockchain/blob/master/docs/event-dispatcher.md#post-drop_mempool_tx
StaleGarbageCollect - transaction was dropped because it became stale
As @diwakergupta said, this happens after a tx has been in the mempool for over 256 blocks.
I agree a better UI could be shown for this condition.
@eugeniadigon mentioned it could make sense to update the wallets with a transaction state that reflects expiration / dropped_stale_garbage_collect as well
Is there anything pending to do here? Or is this issue covered in #1899?
Do we need the 'blank' (transaction expired) page for the Explorer?
Went ahead and designed it: https://www.figma.com/file/31q1g27k69z1yXb6r6vrRD/Explorer?node-id=3485%3A18858
Please advise for the correcting wording... :)
I've tweaked the copy a bit here. Should we add a "Learn more" as well for documentation about expirations?
Can the API just remember the transactions that got dropped?
That way, the user gets more information about what happened, and the whole system looks more robust, because we know we can remember things and things are not just getting dropped.
Seems like there are not going to be too many of these to store.
Can the API just remember the transactions that got dropped?
It does store them. The only time they get lost is if the stacks-node event data changes and we do a full re-sync, dropped mempool txs don't exist anywhere after that.