eth_getTransactionReceipt throws an error when transaction is not found

[charles-cooper]

• Parity Ethereum version: 2.3.8-stable
• Operating system: Linux
• Installation: github release
• Fully synchronized: yes
• Network: ethereum / kovan
• Restarted: yes

When querying eth_getTransactionReceipt for an unmined transaction, I would expect to get either a receipt or null as specified in https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_gettransactionreceipt. Instead, I get an error message like

Transaction with hash: <hash> not found.

[jam10o-new]

Was this transaction one that your node originally broadcast?

[charles-cooper]

Was this transaction one that your node originally broadcast?

Yes

[jam10o-new]

Can you please share the exact messages you're seeing (omitting private information if you wish)? I'm having trouble finding where that error might be emitted from.

[charles-cooper]

@joshua-mir, sorry, I mixed up two error messages I was seeing. The Transaction with hash..not found is generated by my web3 client (as a result of the RPC call returning null). Here's the other error message I see,

{"code": -32000, "message": "Block information is incomplete while
ancient block sync is still in progress, before it's finished we can't determine the existence of requested item."}

Both happen in the same conditions (the node broadcast the transaction but the tx is still unmined), the only difference seems to be whether ancient block sync has finished or not. In the second case, I would expect the node to return null or the transaction. In both cases, I would expect the node to be able to find a transaction it broadcast, but I guess the recently merged JSON-RPC spec EIP has a note which says that the receipt is not available for pending transactions. It's unclear to me whether this is a requirement or an ambiguity for the client developer, but I feel like parity used to return the transaction with blockHash set to null. Will parity be returning null for pending transactions going forward then?
EDIT: Also, I'm not sure I'm consistently getting null vs transaction-with-null-blockhash for unmined transactions.

[jam10o-new]

If you are running a miner or authority, your node will be maintaining a pending block, which is what queries to the pending block reference - that's currently how that ambiguity plays out in parity, but if we decide to implement that rpc spec EIP I'd imagine the ambiguity should be removed. You certainly shouldn't rely on having access to the pending block as a user or developer though.

The reason you are seeing the ancient block sync reference when looking for a transaction that should be in the pending block is simply because we don't know whether it's a replay of an old transaction in a block we aren't aware of intil ancient sync is complete.

[d10r]

I'm seeing the same issue with a Parity node (2.5.5) NOT running as miner/authority.
Looks like this can happen as long as ancient blocks were not fully synced.
If Parity is running with --no-ancient-blocks, the error message changes - see web3/web3.js#1423 (comment) -, but it leads to the same issues when using web3.js.

Please give advice if web3.js should be modified to keep polling when eth_getTransactionReceipt returns an error / that specific error or if it's something which should be changed on Parity side.