Calling `net_listening` on RPCs yields 400's and other http errors on Network tab

[0x33dm]

Check existing issues

• [X] I checked there isn't already an issue for the bug I encountered.

Viem Version

2.16.1

Current Behavior

I have been using the fallback transport, and I noticed it does calls the net_listening function on RPCs.

What I have been observing is that some public RPCs don't implement, most of the time still they reply with 200 OK but sometimes they also respond with a weird 400.

I wonder if instead of net_listening we should change the method to be eth_blockNumber as it's unlikely an RPC won't implement that function and the response time from my location seems to be exactly the same, for instance for flashbots it's around 200ms.

Expected Behavior

No response

Steps To Reproduce

Turn rank on the fallback transport

Link to Minimal Reproducible Example

https://stackblitz.com/edit/viem-getting-started?file=index.ts

Anything else?

for instance:

[jxom]

I wonder if net_version is more supported than net_listening. We can’t really use eth_blockNumber as it would cost consumers Compute Units per call.

[0x33dm]

I wonder if net_version is more supported than net_listening. We can’t really use eth_blockNumber as it would cost consumers Compute Units per call.

Good thinking.

The funny thing I found is that net_listening sometimes isn't implemented, yet they return 200 OK, which is a super good trick to use for monitoring.

Perhaps we could add the name of the function to be called as a parameter on the fallback transport, eth_blockNumber probably doesn't cost much computing tough and it's probably cached on the RPCs

[0x33dm]

Another weird behaviour I see, for instance, with "nodies" public RPC

• it can be 200 OK for sometime
• it can be 503 ( service unavailable )
• CORS errors

From my understanding it basically means sometimes they're fine with taking requests from public ( it's a public node, so that should be the case ), but sometimes they seem to be overloaded ( 503 ) and sometimes they probably just open for their own domain.

Because 503 (I guess any 5xx ) errors generate a lot of "error activity" on the "Console" from browsers, I believe we could consider giving a "cool down" period and exclude the RPC from the ranking algorithm to avoid flooding the console and burying some actual application errors.

[0x33dm]

I wonder if net_version is more supported than net_listening. We can’t really use eth_blockNumber as it would cost consumers Compute Units per call.

To start with, could we make the function used to ping a transport parameter/option wdyt?

For instance, I don't mind using eth_blockNumber, changing it to eth_blockNumber in my case would likely help me stop getting all these error messages on my website/sentry reports.

[0x33dm]

I wonder if net_version is more supported than net_listening. We can’t really use eth_blockNumber as it would cost consumers Compute Units per call.

I created a PR with rankMethod as a parameter. Would really appreciate if you could give me a help with the tests / getting the PR approved.

I understand ideally, we would want a better default, but in the meanwhile, it would be great to add this option.

https://github.com/wevm/viem/pull/2642

[0x33dm]

@jxom any thoughts on this? would really appreciate some help with the PR.

Thank You