429 Too many requests

[danielgangl]

Hey guys, I am having trouble with wagmi making waay too many calls implicitly (about 100 eth_getBalance requests on page load).
Are any of you having the same problem?
I am using wagmi with rainbow kit.

[jxom]

You may need to provide your own Alchemy API Key to alchemyProvider.

[danielgangl]

Yeah I did that...

But even then these are way too many requests. Having even a few users on my we app I will instantly be rate-limited and their experience might be impacted negatively

[Fabien-Morrow]

You have to probably check your app architecture, 100 hooks re-render for getting a balance is way to much.
For me it's not a wagmi problem. I recommend you to read this

[soccerarenadev]

I'm getting that error, but it is not due to too many request.
This is the actual message:
{"message":"Method Not Allowed","logref":null,"path":null,"_links":{"self":{"href":"/v2/asdfasdfasdf","templated":false,"profile":null,"deprecation":null,"title":null,"hreflang":null,"type":null,"name":null}},"_embedded":{"errors":[{"message":"Method [GET] not allowed for URI [/v2/asdfasdfasdf]. Allowed methods: [POST]","logref":null,"path":null,"_links":{},"_embedded":{}}]}}
More info: #1133

[danielgangl]

I just noticed that the issue does not happen anymore when I remove rainbow kit - so thats more likely the problem.
Thank you for your answers!

[soccerarenadev]

I just noticed that the issue does not happen anymore when I remove rainbow kit - so thats more likely the problem. Thank you for your answers!

Still shouldn't happen in Wagmi as it should fallback to the next provider instead of failing.

[dev-cz]

I just noticed that the issue does not happen anymore when I remove rainbow kit - so thats more likely the problem. Thank you for your answers!

I also have this issue with Rainbow. Hmmm also have my own Infura Key and it burned right through it.

[REPTILEHAUS]

Is there any more info about this and Rainbowkit

[rsodre]

I have the same problems here (429 and Method not allowed), and I'm working on a local ganache server.
I can get a key, but I'm afraid to burn it.
Why would wagmi be so heavy on mainnet when working locally?

[tmm]

It shouldn't taking a look into it!

[rsodre]

Do wagmi still use the publicprovider, or configured provider, after I connect to MetaMask?
I never fetch anything before connecting to MetaMask.

[dev-cz]

Did someore digging into this, and it does seem like a wagmi issue.

If I don't use alchemy and provide an Infura Key, the issues is still there and prevents even Infura from being used, and actually spams the Infura API calls.

So far what I have found work is to add an Alchemy key, and Infura Key then set priority and that fixes the issue.

Issues has only been there last few weeks so not sure what changed.

[dev-cz]

Like this? Seems to be working normally again here.

const { provider, webSocketProvider } = configureChains(chains, [
	infuraProvider({
		apiKey: process.env.INFURA_API_KEY,
		priority: 0,
	}),
	alchemyProvider({
		apiKey: process.env.ALCHEMY_API_KEY,
		priority: 1,
	}),
	publicProvider({
		priority: 2,
	}),
]);

Yep! That's how I have it and how I was able to work around the issue until wagmi team has a fix.

[jxom]

You don't need to add a priority as wagmi does that internally. An API key is enough!

There is an open PR to migrate away from the public Alchemy RPC URLs in publicProvider.

[dev-cz]

You don't need to add a priority as wagmi does that internally. An API key is enough!

There is an open PR to migrate away from the public Alchemy RPC URLs in publicProvider.

Correct, but if your goal was to use Infura, then you do need the priority, but in any case you could use either at that point.

[jxom]

You don't need priority if it is listed first in the array.

[johnpaulcas]

You don't need priority if it is listed first in the array.

Hi @jxom so are we gonna set the publicProvider to be the first in the list? also when infura reach the limit it seems it doesnt change the provider

[a-znk]

I'm experiencing a similar issue with my project as well! I didn't make a single change to it, started back on developing a few days later, and BAM, exhibiting this behavior now.

[a-znk]

Thank you! I'm building my project using NextJs, and I've found that I need to add "NEXT_PUBLIC" to my environment variable in this instance. Otherwise, I receive this message "Error: could not detect network (event="noNetwork", code=NETWORK_ERROR, version=providers/5.7.2)".

As a result, my Alchemy API key is exposed in DevTools. I was thinking perhaps I could find a way to make that API call in an API route, but wasn't sure if/how that might work. Any suggestions on how to add this key more securely?

[rsodre]

I use next.js also and it does not expose it when I configure it just like the Getting started tutorial.
But when that happens, a simple workaround is to create an api endpoint on your server, and call the external api from there

[Fabien-Morrow]

I'm stuck with this too :

• If I put NEXT_PUBLIC to my env variables, wagmi can properly initialise the providers but they are exposed client side.
• If I remove NEXT_PUBLIC, wagmi can't initialise this client side for calling the hooks and switch to default provider, with very low rate limit.

How did you manage this @rsodre ? Do you have an _app to paste ?

[tmm]

If I put NEXT_PUBLIC to my env variables, wagmi can properly initialise the providers but they are exposed client side.

They are publishable keys and need to be in the JS bundle to work.

[rsodre]

How did you manage this @rsodre ? Do you have an _app to paste ?

API routes in nextjs are always executed on the server.
If I need anything from Infura, for example, I have a hidden route like /api/infura/getbalance that will do the actual fetching.

Or use server side props, also guarantee to run on the server

[gpxl-dev]

I think by default retries are very agressive here too. It would be ideal if we could listen for 429s and throttle back retries in those events.

This also relates to this request - please throw on an upvote!
#950

[jxom]

Yeah that would be nice, unfortunately we don't have control over the retry timing. It internally uses ethers' exponential backoff algorithm for retries.

[gpxl-dev]

Ah that makes sense, good to know!

[thekesslereffect]

Having the same 429 issue as everyone else. Any fix for it yet?

[newbluestudios]

Also having this issue with Rainbowkit. Can't figure out what went wrong. The docs don't have all the info to fix the issue either 😭

[johnpaulcas]

Im having same issue, 429 im using connectKit, I just add new alchecmy and this error occur even on the first few request

[newbluestudios]

for me this fixed it (above)

const { provider, webSocketProvider } = configureChains(chains, [
infuraProvider({
apiKey: process.env.INFURA_API_KEY,
priority: 0,
}),
alchemyProvider({
apiKey: process.env.ALCHEMY_API_KEY,
priority: 1,
}),
publicProvider({
priority: 2,
}),
]);

[johnpaulcas]

for me this fixed it (above)

const { provider, webSocketProvider } = configureChains(chains, [ infuraProvider({ apiKey: process.env.INFURA_API_KEY, priority: 0, }), alchemyProvider({ apiKey: process.env.ALCHEMY_API_KEY, priority: 1, }), publicProvider({ priority: 2, }), ]);

thanks! will try this one

[johnpaulcas]

anyway to like used, the metamask as default provider if connected? than using alchemy or infura as provider as 429 occur a lot, hope to hear from the team soon, thanks!

[gpxl-dev]

Upvote #950

[arthur-zhuk]

Someone mentioned that the issue goes away if you remove process.env from the evaluation and just hard code the api key as a string. That works, but, why is this bug suddenly alive and hasn't been addressed?

[johnpaulcas]

same! maybe if they know some solution, they can provide it to docx and wondering if than just using alchemy or infura as provider, we can just get the default connected wallet like metamask for example as default provider.

[rafinskipg]

I found the problem people.

Alchemy provider accepts one "api_key" , that is used for several networks. But that doesn't work!

Each API_KEY in alchemy is only for one network.

So this setup will work for the default network you created your apikey for , but not for others.

I think it needs a rewrite on wagmi alchemy provider

[tmm]

Unless something changed on their end, Alchemy API keys should work across networks (it only looks like in the dashboard that they don't).

[rafinskipg]

yes you are right i was confused, trying to find a solution xDD

[ackvf]

This sucks as it seems to ignore the setting for stallTimeout. This is my config

const { chains, provider, webSocketProvider } = configureChains(
  getSupportedChains(),
  [
    publicProvider({
      priority: 0,
      stallTimeout: 1000,
    }),
    alchemyProvider({
      priority: 1,
      apiKey: ALCHEMY_API_KEY,
    }),
  ],
  {
    stallTimeout: 1000,
  }
)

This says that after a second it should switch from publicProvider to alchemyProvider.

I do indeed see a request with my own alchemy key after a second, which retrieves the expected result, but the public provider still keeps firing even after a minute. WTF??

Changing the priority from public:0 alchemy:1 to public:1 alchemy:0 solves the issue and there are no longer this many requests, but just one.

[ackvf]

Just a heads up guys, the 429 Issue was solved in latest versions of wagmi where they changed the default RPC url for the troubling chains.
Just upgrade to latest wagmi and you should be K.

/edit The issue was that the Alchemy url with an actual API key was hardcoded in previous versions of wagmi, ignoring whatever you set.

[ackvf]

@johnpaulcas the api key was hardcoded in the chain configuration, look here 389765f

This was the one failing for everyone https://eth-goerli.alchemyapi.io/v2/_gg7wSSi0KMBsdKnGVfHDueq6xMB9EkC. You can even search it with google _gg7wSSi0KMBsdKnGVfHDueq6xMB9EkC and find many related issues.

But what I am seeing in your request url is that you are using different key, so maybe you are using your api key and have reached the quota on it too?

[johnpaulcas]

@ackvf actually thats api is just newly added, Im using a loop and inside of loop are watch option enabled, maybe because consecutive call in alchemy is not allowed, but when I switch it to infura, it works just fine

[johnpaulcas]

weird, I switch the ordering and now my alchemy works 🤔

[rsodre]

I also still keep seeing the error all the time, with the public key.

I import ethers on some components to use ethers.utils, should that be the cause?

const { ethers } = require('ethers');

What is the proper way to import ethers with wagmi?

[rsodre]

Nevermind, my keys were not visible.

[Hussainzz]

it's weird latest version of WAGMI seems to throw a rate limit 429 error with alchemyProvider.
but it works fine with "wagmi": "^0.8.8"

const { chains, provider, webSocketProvider } = configureChains(
  [polygon, polygonMumbai],
  [
    alchemyProvider({ apiKey: process.env.REACT_APP_ALCHEMY_API_KEY }),
    publicProvider(),
  ]
);

[devlancer412]

I didn't use alchemy api. but it sends too many request and all response are 429 error.
Please help me.

const { chains, provider } = configureChains(
  [flare, ...(process.env.NODE_ENV === "development" ? [coston2] : [])],
  [
    jsonRpcProvider({
      rpc: (chain) => ({
        http: RPC_URLS[chain.id],
      }),
    }),
  ],
  { pollingInterval: 10_000, targetQuorum: 3 },
);

export const client = createClient({
  autoConnect: true,
  connectors: [
    new MetaMaskConnector({ chains }),
    new CoinbaseWalletConnector({
      chains,
      options: {
        appName: "wagmi",
      },
    }),
    new WalletConnectConnector({
      chains,
      options: {
        qrcode: true,
      },
    }),
  ],
  provider,
});

[Stenor5]

I didn't use alchemy api. but it sends too many request and all response are 429 error. Please help me.

const { chains, provider } = configureChains(
  [flare, ...(process.env.NODE_ENV === "development" ? [coston2] : [])],
  [
    jsonRpcProvider({
      rpc: (chain) => ({
        http: RPC_URLS[chain.id],
      }),
    }),
  ],
  { pollingInterval: 10_000, targetQuorum: 3 },
);

export const client = createClient({
  autoConnect: true,
  connectors: [
    new MetaMaskConnector({ chains }),
    new CoinbaseWalletConnector({
      chains,
      options: {
        appName: "wagmi",
      },
    }),
    new WalletConnectConnector({
      chains,
      options: {
        qrcode: true,
      },
    }),
  ],
  provider,
});

I have same issue while using wagmi.

[firnprotocol]

related question: how do we "respect" the user's choice of custom RPC?

i.e., let's say that the user manually adds a custom chain into MetaMask, with Optimism's chainID, but with a custom RPC URL (e.g., pointing to their own alchemy).

i am using the standard publicProvider. it appears that in this setting wagmi still sends connections through the public Optimism gateway, mainnet.optimism.io. i.e., it's ignoring the RPC url set in the wallet extension, and instead using something hardcoded in wagmi.

how do we respect / defer to the (custom) RPC url set in MetaMask? thanks in advance.

[tmm]

See #950 (comment)

[firnprotocol]

thanks for the heads-up. it looks like it is possible, à la this comment?

my main motivation here is privacy. as a privacy-oriented application, i want to defer to the user's choice of RPC, if they have reason to use something custom. (there are plenty of reasons why one might want to use a custom RPC.)

[jxom]

Probably. But it is pretty much impossible to guarantee determinism if you rely on the user to set their own RPC, which may lead to many bugs in your dapp. The RPC may lack compatibility, become compromised, or have poor rate quotas. These problems don’t exist if the dapp can sensibly choose which RPC(s) they want to route through.

[firnprotocol]

i certainly agree with you that there are cons; on the other hand, there are also pros (see my comment). so it's a matter of tradeoffs. in any case, for my future reference, it'd be helpful to know if there was a "minimal" / easy way to achieve this functionality, just so that i can test it? something like this approach? keep in mind my code only uses configureChains and createConfig, but not createClient; this appears to be the "new" way of doing things. thanks in advance for your patience.

[REPTILEHAUS]

Im not sure if this is related but im getting this when metamask popup opens MetaMask/metamask-extension#27099