Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle Dropped & Replaced Transactions #259

Closed
micahalcorn opened this issue Sep 27, 2020 · 6 comments
Closed

Handle Dropped & Replaced Transactions #259

micahalcorn opened this issue Sep 27, 2020 · 6 comments
Assignees
Labels
dapp Relating to OUSD.com enhancement New feature or request P1 Large amount of significant user impact, a meaningful feature is broken

Comments

@micahalcorn
Copy link
Member

micahalcorn commented Sep 27, 2020

If a user decides to "speed up" her transaction by submitting a second one with the same none and a higher gas price, our DApp is unaware of the new transaction and gets stuck waiting for the old one. This is a common problem with no simple solution yet.

See the following:

@micahalcorn micahalcorn added enhancement New feature or request P2 Small number of users are affected, major cosmetic issue dapp Relating to OUSD.com labels Sep 27, 2020
@joshfraser
Copy link
Contributor

In the meantime...

Until the transaction is confirmed, we could continue watching the blockchain for additional transactions that are signed by the original wallet & see if they look like replacements. Doesn't seem too hard.

@sparrowDom
Copy link
Member

From my research when a client wants to increase gas it creates another transactions with higher gas price and the same nonce. Now the problem is that the web3 browser / Metamask do not communicate this back to the Dapp. There are some proposed solutions (that Micah outlined above) but nothing we could use today.

I see 2 ways we could get this done:

  1. slower way - develop a backend that listens to the blockchain for all events / transactions on OUSD contract and expose that data via API. We could use @DanielVF 's debug.ousd.com for that, or fork it and develop a separate service. We need a similar service anyway to display all the debug information that were once part of the DApp designs.
  2. faster way - use Etherscan API and pass the api key to the client to fetch all the transactions of an account. And see if there is a transaction that has replace the initial mint/redeem/allow one.

Personally I think the option 2 is not so messy and doable relatively quickly and would vote for that one if we want to have this functionality reasonably quickly. Actually I see that Etherscan allows 1 request every 5 seconds to their api without the need for an API key. That is more than enough to get the latest 20 transactions of an account and check for possible gas price upgrade transaction.

@shahthepro
Copy link
Collaborator

shahthepro commented Sep 28, 2020

I would suggest to subscribe to new transactions using WS provider and adding a from filter instead of polling though. May be when the page reloads, you could use Etherscan API to get the states of tx in localStorage quickly

@sparrowDom
Copy link
Member

That might be even more elegant, thanks @shahthepro !

@sparrowDom sparrowDom self-assigned this Oct 1, 2020
@micahalcorn micahalcorn added this to the 10/01/20-10/14/20 milestone Oct 1, 2020
@micahalcorn micahalcorn added P1 Large amount of significant user impact, a meaningful feature is broken and removed P2 Small number of users are affected, major cosmetic issue labels Oct 2, 2020
@sparrowDom
Copy link
Member

PR for this issue: #304

@micahalcorn
Copy link
Member Author

@kayyoo23 reported that her replacement transaction for token allowance was not picked up. Was the fix in #304 intended to handle these too or just mints and redeems?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dapp Relating to OUSD.com enhancement New feature or request P1 Large amount of significant user impact, a meaningful feature is broken
Projects
None yet
Development

No branches or pull requests

4 participants