Getting Error 32603 on getLogs

Hi! We’ve been getting this error whenever we try to get logs:
[{"jsonrpc":"2.0","id":5,"error":{"code":-32603,"message":"request processing failed"}}]

This was working just fine before but it starting failing after the new project id system was put in place (we’re not sure if it started right after the change or some time later).

Everything else is working fine except for the eth_getLogs calls.

this is our request:

curl -H 'Host: rinkeby.infura.io' -H 'accept: application/json' -H 'content-type: application/json' -H 'user-agent: my-proj/9 CFNetwork/958.1 Darwin/18.0.0' -H 'accept-language: es-es' --data-binary '[{"jsonrpc":"2.0","method":"eth_getLogs","id":5,"params":[{"toBlock":"latest","fromBlock":"0x2dc6c0","topics":[["0x6ae5a1ae454eae14fdd60dea5b49ec86610f748636d92fee08931ec6631a8a42"]],"address":["0xe6aB84Cd8f7d4ee829C3325a02695F2e336CC03f"]}]}]' --compressed 'https://rinkeby.infura.io/v3/22f2364e56ec44878177c9fb17f4a9db'

if we check in https://rinkeby.etherscan.io/tx/0x404fbb3b86c733a39996ede503eae50a984118b236ff3338b4aef2a69bed6979#eventlog we can see that there’s 1 event in that contract with a matching topic and 2 parameters (both addresses)

Thanks for reporting this issue, this helped us identify a performance issue with how we are handling batch requests which is leading to this error. While we fix this issue on our side you can the request as a stand alone RPC instead to resolve the issue on your side.

Awesome, standalone RPC are working, thanks a lot!

Using web3.py’s w3.eth.getLogs gives the following error: {'code': -32603, 'message': 'internal error'}. What remedy is there to this?

Hi Robert. What parameters were passed into the function and for which network?

Hi @egalano,

working on Rinkeby, using the following line of code.

logs = w3.eth.getLogs({'fromBlock': 'pending', 'toBlock': 'latest', 'address': FACTORYADDR})

Hi Robert. Thanks for reporting this. I think you might have found a bug and I’m going to look into this with our team asap. I’ll keep you updated on what we find and if a fix is necessary, what the timeline would be.

In the meantime, can you retry your web request without the ‘pending’ fromBlock filter? I believe that is what is causing the issue.

Ok, thanks @egalano.

Getting the following when turning to JSON-RPC for getLogs:

{'code': -32601, 'message': 'The method eth_newFilter does not exist/is not available'}

Per our docs, we don’t support eth_newFilter over the JSON-RPC API. We recommend that for a more stable data experience people utilize websocket subscriptions see the example here

I also was able to confirm that this seems to be a bug in the geth client. Geth seems to hang when a fromBlock of pending is set in the request. The Parity client seems to support this just fine though. I’ll be filing a bug with the go-ethereum team at https://github.com/ethereum/go-ethereum.