Skip to content
This repository was archived by the owner on Nov 6, 2020. It is now read-only.

eth_getTransactionByHash blockNumber is set, even though the transaction isn't mined yet #6864

Closed
pcppcp opened this issue Oct 23, 2017 · 0 comments
Assignees
Labels
F2-bug 🐞 The client fails to follow expected behavior. M6-rpcapi 📣 RPC API.
Milestone

Comments

@pcppcp
Copy link

pcppcp commented Oct 23, 2017

I'm running:

  • Parity version: v1.8.0
  • Operating system: Linux
  • And installed: compiled from source (git branch v1.8.0)
  • Chain: Ropsten

According to the JSON RPC specification, blockNumber item returned in the result of eth_getTransactionByHash call should be set to null if the transaction is pending.

In Parity, it is set to an actual block number (probably block id at the time the transaction has been submitted), even though the tx hasn't been mined yet.

>>> transaction_hash = '0xb5430d004d1383aa1955b6827770b578c86711f9eadaca103bcd6bb03e87c859'
# right after the tx has been submitted
>>> tx_pending = self.call('eth_getTransactionByHash', transaction_hash)
# this should be null (or None in python)
>>> tx_pending['blockNumber']                                                                              
u'0x1d67cf'
# wait until the tx is mined
>>> tx_mined = self.call('eth_getTransactionByHash', transaction_hash)
>>> tx_mined['blockNumber']                                                                                       
u'0x1d67d2'

EDIT: this happens only with v1.8.0, v1.7.7 branch behaviour is correct.

@tomusdrw tomusdrw self-assigned this Oct 23, 2017
@tomusdrw tomusdrw added F2-bug 🐞 The client fails to follow expected behavior. M6-rpcapi 📣 RPC API. labels Oct 23, 2017
@5chdn 5chdn added this to the 1.9 milestone Oct 30, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
F2-bug 🐞 The client fails to follow expected behavior. M6-rpcapi 📣 RPC API.
Projects
None yet
Development

No branches or pull requests

3 participants