-
Notifications
You must be signed in to change notification settings - Fork 854
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Race condition in JsonRpcExecutor
#4192
Comments
We are also seeing this bug, it's a blocker for us to use Chainlink with Besu. We need reliable RPC calls. One example RPC call that triggered it:
Note that this usually returns the correct payload:
But, sometimes it instead returns The problem is intermittent. |
@samsondav I am assuming this was found on goerli based on the domain in your curl command. Is that true? If so how frequently and how long did you loop this statement to create the "Block not found" error. I have not yet been able to reproduce it. |
@samsondav, checking in again. Are you still seeing the error? If yes, we would love to help investigate the issue. |
@samsondav , We still have this bug in our private QBFT deployment |
same issue here. |
I use Besu and call Errorsomething like this.
frequencysometimes I got the error 90 times when i try 420000 times. |
I have not yet been able to reproduce it. |
Description
We started noticing that when we're frequently using the
eth_call
method, every now and then it would fail unexpectedly with theBlock not found
error.After observing the logs I believe the issue is a race condition:
Logs from the time the error occured:
Logs from other calls to
eth_call
that didn't fail:the fact that the error case has
BftProcessorExecutor
logs mixed withJsonRpcExecutor
makes me believe that some sort of race condition is occuring, but that's all I was able to figure out.Steps to Reproduce (Bug)
eth_call
with with any smart contract methodExpected behavior:
No errors
Actual behavior:
Besu returns
Block not found
Frequency:
We saw it occuring say after 2 or so minutes of running our software.
Versions
Docker image labels:
22.7.0-RC2-SNAPSHOT
We observed this issue on M1 MacBooks and also on our CI - which last time I checked was running various generations of Intel Xeon.
The text was updated successfully, but these errors were encountered: