-
Notifications
You must be signed in to change notification settings - Fork 286
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
[Bug] Deserialization error on get_block for pending data on BSC #2117
Comments
It happens on BSC chain and it seems to be related to a mapping type. |
this is an invalid response according to the spec https://ethereum.github.io/execution-apis/api-documentation/ this is missing hash, miner,nonce fields imo this is something that bsc should fix by adding them mind opening an issue for this on bsc? this should be easily fixable |
Well we do not expect to get a hash, miner, nonce value when fetching a pending block since we are fetching the block that is currently being processed, it is not validated yet. Am I missing something here? |
if that were the case, why does it have a stateroot? this goes against the eth spec and is trivial to fix |
For comparison {
"hash": "0xd12f672f223d2981f406204b3c7daac6414a6e6a5be343aaa0d7dc73b688a169",
"parentHash": "0x025760e3c1483879bdba2b80f63f7c05705b9166d1e4c9bd66916e83e07ab81b",
"sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
"miner": "0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5",
"stateRoot": "0x732e4b59b01efc8e3d2d37aa0269f54d3ae3b6330f97f9d23cae39c786186699",
"transactionsRoot": "0xb35b9355d565eece9c9428cdf816e15d2e9243a1d6dd1b4fede1cd25407cabc6",
"receiptsRoot": "0x93de668a875c6c4542b9d7fc88198cc35696c63570a4928b89004cf53f250f28",
"logsBloom": "0xb5fad0e665c199b6389a726ceba9f2b59182b72b368271a5f7a9405b740dfd2092557004ee91b46863d27f53e9a2e79f7a59ad6bdc93a4e656ff952963273909be438c6ca3f003aeaef073ad9c2b32e741ee48fe0657b269e4f65958d3d58fd3d9cfa575bb6eab81b4b23e98350aaacfcee9d6ee058c4ea77d1135fedc3d4f0089f8b62e9fd663384fafcf74b716863e050fc48799ba9a7bbdfe795c2d9661070fe228d127c920d2481529e09695b19e0bdeac0cd2b5311b34eb84349c28b35f659abd4f5d373c7f2b4e9bb10b5b1df0d5b91273d7aa9bd22e696d4720b0ba023b59bd543504ef8e946db664a572fff1b76d9d989afc9349d11a367bcb7ccea7",
"difficulty": "0x0",
"number": "0x14eab56",
"gasLimit": "0x2243e7d",
"gasUsed": "0x19a3fea",
"timestamp": "0x67bf78ef",
"extraData": "0x6265617665726275696c642e6f7267",
"mixHash": "0x90bbdc2ef2ed06b2b2c7471ce566e290fc9f710cb5688ebafa96e39a1dce3d27",
"nonce": "0x0000000000000000",
"baseFeePerGas": "0x9d136963",
"withdrawalsRoot": "0xafe0451e4624ac8173fd5f606b97f58b6e37907634061a6531be6059cf138ff8",
"blobGasUsed": "0xc0000",
"excessBlobGas": "0x4980000",
"parentBeaconBlockRoot": "0xbd82d2b5fb0fbfaa357c81f78bc116bf2fa845b8f7483198aa43f74f8df6caaa",
"size": "0x29256",
"uncles": [],
"transactions": [],
"withdrawals": []
} |
Thank you guys for your reply,
Note: Thank you @DaniPopes for reformatting my first comment :) |
thanks for flagging, I can open an issue on bsc for this, this is likely just an oversight in rpc response handling. for alloy this is a no-fix because this response is off spec the pending block number is |
Closing as no-fix per discussion above |
I think this issue should be re-opened, as it also affects mainnet with reputable public RPCs. Even if this is not spec-compliant, if most people are having issues maybe the case should be handled regardless. See the following repro: https://github.com/beeb/repro-alloy-ws
I observed the same response with meowrpc, infura, ankr and quicknode on https so it's a widespread problem.
|
I think we can just use fake values for the missing fields then |
@beeb do you know what the clients are? the missing values are clearly used when the pending block is built so idk why they don't return them |
No idea, but it must something quite popular since a lot of the public RPCs have the same behavior. I agree that using fake values would be acceptable for a pending block. |
idk why this exists: goes clearly against spec |
I think the spec might have changed over time, see these old references to even the EDIT: For example, the hash was made mandatory here ethereum/execution-apis@8fcafbb |
I found an example of documentation which states that many values should be null for pending blocks: https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbyhash |
Encountered this today with Alchemy. It fails to deserialize for an Eth mainnet endpoint, but works fine, for example, for Base. |
@alexfertel also the pending block? |
Yeah, that's right. This code: use alloy::{
eips::BlockNumberOrTag,
providers::{Provider, ProviderBuilder},
rpc::types::BlockTransactionsKind,
};
#[tokio::main]
async fn main() {
let rpc_url_http = "https://eth-mainnet.g.alchemy.com/v2/$KEY"
.parse()
.unwrap();
let provider = ProviderBuilder::new().on_http(rpc_url_http);
let b = provider
.get_block_by_number(BlockNumberOrTag::Pending, BlockTransactionsKind::Hashes)
.await
.map(|b| b.unwrap().header.number)
.unwrap();
println!("pending {:?}", b);
} Errors with this:
|
fix in progress now, really wish clients wouldn't do this for no reason |
Component
serde
What version of Alloy are you on?
0,11,1
Operating System
Linux
Describe the bug
Hello,
I'm getting a deserialize error when trying to fetch pending block data using
provider.get_block(BlockId::pending(), BlockTransactionsKind::Hashes)
JSON:
The text was updated successfully, but these errors were encountered: