When a key purchase transaction fails because the user re-initiated it outside of the paywall (for example, with a higher gas price), we need to detect this condition.
The only time we can detect this is when it becomes a pending transaction. If a transaction is pending or higher, and becomes submitted, this means it was reverted.
On a finer level of detail, if eth_getTransactionByHash returns a value, and then later returns null, this means the transaction has been reverted, and we should no longer respond to it.
Over the long-term, we will need to use rover to retrieve transactions, as the real risk comes from a cleared cache.
If the cache is cleared, and we have a transaction returned from locksmith which does not exist yet in the mempool, it will be marked as submitted.
We could decide that if a transaction is older than 12 hours and is still submitted that it is to be ignored, or some other heuristics.
This issue is specifically responding to @cnasc 's adventures last week, and I would love to open a discussion on a long-term fix with @julien51 as well.
Note that #4409 temporarily disables the localStorage cache to fix another bug, and this may also fix the issue @cnasc had, but I suspect that it may not, because locksmith still returns the transaction hash of the failed transaction, and we will probably still consider it submitted and wait for the dead transaction to resolve.
julien51
commented
4 years ago
When a key purchase transaction fails because the user re-initiated it outside of the paywall (for example, with a higher gas price), we need to detect this condition.
The only time we can detect this is when it becomes a pending transaction. If a transaction is pending or higher, and becomes submitted, this means it was reverted.
On a finer level of detail, if
eth_getTransactionByHashreturns a value, and then later returnsnull, this means the transaction has been reverted, and we should no longer respond to it.Over the long-term, we will need to use
roverto retrieve transactions, as the real risk comes from a cleared cache.If the cache is cleared, and we have a transaction returned from locksmith which does not exist yet in the mempool, it will be marked as
submitted.We could decide that if a transaction is older than 12 hours and is still submitted that it is to be ignored, or some other heuristics.
This issue is specifically responding to @cnasc 's adventures last week, and I would love to open a discussion on a long-term fix with @julien51 as well.
Note that #4409 temporarily disables the localStorage cache to fix another bug, and this may also fix the issue @cnasc had, but I suspect that it may not, because locksmith still returns the transaction hash of the failed transaction, and we will probably still consider it submitted and wait for the dead transaction to resolve.