search

trufflesuite / ganache

:warning: The Truffle Suite is being sunset. For information on ongoing support, migration options and FAQs, visit the Consensys blog. Thank you for all the support over the years.
https://consensys.io/blog/consensys-announces-the-sunset-of-truffle-and-ganache-and-new-hardhat?utm_source=github&utm_medium=referral&utm_campaign=2023_Sep_truffle-sunset-2023_announcement_
MIT License
2.61k stars 676 forks source link

eth_feeHistory not working in Ganache in docker #4321

Closed Johnhersh closed 1 year ago

Johnhersh commented 1 year ago

I'm running Ganache off of the docker image "trufflesuite/ganache:v7.7.7". Most everything works fine, except when I try and call eth_feeHistory I get this response:

{
    "id": null,
    "jsonrpc": "2.0",
    "error": {
        "message": "header not found",
        "stack": "Error: header not found\n    at BlockManager.get (/app/dist/node/1.js:2:43929)\n    at async EthereumApi.eth_feeHistory (/app/dist/node/1.js:2:94246)",
        "code": -32700
    }
}

This seems related to EIP-1559. Is there some setting that needs to be turned on for this to work?

davidmurdoch commented 1 year ago

Can you provide reproduction steps?

Johnhersh commented 1 year ago

I'm so sorry, after trying to reproduce this I realized I made a very stupid typo and actually the problem is probably with the library I'm using to access Ganache. Very sorry for wasting your time :(

davidmurdoch commented 1 year ago

No problem. Let us know if we could have errored better here.

Johnhersh commented 1 year ago

So the input I sent to Ganache is this:

{
    "jsonrpc":"2.0",
    "method":"eth_feeHistory",
    "params":[
        1, 
        4,
        [1, 99]
    ]
}

The error it returns is "header not found", which matches the error I got in the library I was using. I talked to the library authors and they said maybe something is wrong with Ganache and I assumed that was the case. However, I changed my input to this:

{
    "jsonrpc":"2.0",
    "method":"eth_feeHistory",
    "params":[
        1, 
        "latest",
        [1, 99]
    ]
}

And it worked fine. So the initial header not found error didn't communicate exactly what was wrong, which is I left the highest block number parameter as a number when it should be "latest". I imagine the library author ran into the same issue, and I'll check with him to see if we can address it there.