Return rpc error in eth_getLogs on unknown block hash #8051
+32
−12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR description
Fixed Issue(s)
Fixes #8007
The issue describes the problem well, so I won't repeat it here.
The root cause is
org.hyperledger.besu.ethereum.api.query.BlockchainQueries.matchingLogs
detects an unknown hash and returns an empty list. This was the desired behaviour at some point in time, as there was even a test to validate it.I have updated the method to throw an exception in this situation now, as IMO it really is a bad input if it's being called with an unknown hash. This has potentially larger impacts as there are other callers of this function, but to my knowledge they are all passing in a valid hash (acquired via a
BlockHeader
). An alternative approach could be to just patchEthGetLogs
and check the block header prior to callingmatchingLogs
, which limits the impact.I'm not sure if it's ok to be throwing an
InvalidJsonRpcParameters
from within theorg.hyperledger.besu.ethereum.api.query
package, there do not seem to be any other imports, so let me know if that should be cleaned up (I originally was going to raise a new exception type here, but I also noticed this package doesn't have any custom exceptions either).Finally I am re-using the existing
RpcErrorType.BLOCK_NOT_FOUND
for this response, as I did not want to introduce a type to keep the change small. But I can if that is better.ℹ️ I could not run the acceptance tests locally, they killed my (high-end) laptop.
Thanks for sending a pull request! Have you done the following?
doc-change-required
label to this PR if updates are required.Locally, you can run these tests to catch failures early:
./gradlew build
./gradlew acceptanceTest
./gradlew integrationTest
./gradlew ethereum:referenceTests:referenceTests