-
Notifications
You must be signed in to change notification settings - Fork 1.7k
eth_getTransactionReceipt doesn't return a block number while a token transfer call #10623
Comments
eth_getTransactionReceipt returns a null blocknumber if the transaction is not mined yet. This behaviour diverges from geth, which return null instead of any receipt - parity-ethereum returns a receipt if it is aware of the requested transaction but it is unconfirmed. |
From the documentation:
|
From geth's documentation. This divergence has been present for a long while (since 2016, see #3482) |
Thanks for referencing the issue. Is there any effort from the node developers to have the JSON-RPC API in sync? @gavofyork @joshua-mir |
@nivida there is a draft-stage EIP open to standardise the specification between clients ethereum/EIPs#1474 Sorry, you're right, but in this case the reciept is found but it is in the transaction pool/pending block. |
Thanks for referencing the EIP-1474 but it's also there not documented as Parity has implemented it. |
It's a draft-stage EIP, at this stage copied directly from the Ethereum wiki. In the PR comments, you can see some discussion around the discrepancies between geth and parity. |
If you want to see even more discussion around this, we also have #10550 with some additional explanation on why the difference exists. |
Closing issue due to its stale state. |
Steps to reproduce
Send tokens using web3 library
It throws an error "Invalid params: invalid type: null, expected a block number or 'latest', 'earliest' or 'pending'." because eth_getTransactionReceipt doesn't return a block number (see RPC calls below).
RPC calls traces
The text was updated successfully, but these errors were encountered: