mirror of
https://gitlab.com/pulsechaincom/erigon-pulse.git
synced 2024-12-22 11:41:19 +00:00
f9acbff96c
When testing with `Bor` consensus turned on I discovered that `SendRawTransaction` returns a 0x000... hash when transactions are submitted during block transitions. This turns out to be spurious in the sense that the transaction insertion is successful. The cause is that `ReadCurrentBlockNumber` returns a nil block number. This in turn is caused by the following: In `accessors_chain.go` there are two methods: `WriteHeader` and `WriteHeadHeaderHash` when the first is called the block number is written for the header. The second writes the header has, but there is no guarantee when it does that the head header will have been written yet. In fact it seems to happen sometime later. The problem for `SendRawTransation` is that it begins a transaction after inserting into the txpool. And depending on timing this transaction may see only the `WriteHeadHeaderHash` insertion, and hence can't read the block number. I have mitigated this by opening the db transaction before calling the tx pool insertion, meaning that it is more likely to have a clean view of the DB. I have also moved the chain id check earlier in the code - as I think that if this is invalid the method should not try to insert transactions in the first place. The `ReadCurrentBlockNumber` is only used to produce a log message - so I've changed this to not fail the whole function but to just log an unknown sender. Which means that the hash is still returned to the sender after a successful txpool insertion |
||
|---|---|---|
| .. | ||
| abigen | ||
| bootnode | ||
| caplin-phase1 | ||
| caplin-regression | ||
| devnet | ||
| downloader | ||
| erigon | ||
| erigon-el | ||
| erigon-el-mock | ||
| erigoncustom | ||
| evm | ||
| hack | ||
| integration | ||
| observer | ||
| p2psim | ||
| pics | ||
| prometheus | ||
| release | ||
| rlpdump | ||
| rpcdaemon | ||
| rpctest | ||
| sentinel | ||
| sentry | ||
| state | ||
| txpool | ||
| utils | ||
| verkle | ||