Bug: Excessive Errors in the Console
jazzz opened this issue · 5 comments
Describe the bug
Excessive errors in the devtools console. First reported by @prashantpbagga
Steps to Reproduce
- Go to 'vercel.xmtp.com'
- Login in with your Blockchain account
- Inspect
Occurs after login, without any further user action.
Expected behavior
Not lots of errors.
Screenshots
Additional context
Add any other context about the problem here.
Desktop
Please complete the following information if you think it is relevant to the bug:
- OS & Version: [e.g. macOS 13.0.1]
- Browser & Version: [Brave 1.46.140]
Steps to repro addition: attempt to log in with WalletConnect to trigger the issue. Metamask login worked fine for me.
@snormore - points out that we're likely not using the right InfuraID. He's looking into that work thread now.
I'm looking into why we're getting so many requests in the first place if there's a 800ms retry timeout. I believe we're invoking this effect https://github.com/xmtp/example-chat-react/blob/main/hooks/useWalletProvider.tsx#L106-L107 to initialize a walletConnect provider 12 times in quick succession when a user connects with WalletConnect.
See "invoking effect" log line in this screenshot. These 12 initializations match the spamming behavior which is 10-12 requests punctuated by a short 800ms delay
I'm tracing the hooks a bit, still not exactly sure of why we're getting multiple provider initializations but here are some clues:
In a release build (xmtp.chat) we see 6 duplicate web3Modal HTML tags. In a dev build we see 12 (React doubles some hooks in dev). It looks like multiple provider instances are created independently and all will separately retry their connections, or poll.
Screenshots from a local build:
I'm able to reproduce this! Looks like this is causing ENS resolution to fail as well. We'll prioritize.
At least part of the problem is that we are giving our Infura API key away to the public in our code, who can then abuse it and eat up our rate limit.
We should use a separate key with a paid account for our deployed versions of our 1P apps. We can lock the key to our 1P domains to avoid people stealing that one.