--dev: transactions get stuck in pending

[domohawk]

System information

$ geth version
Geth
Version: 1.10.6-stable
Git Commit: 576681f29b895dd39e559b7ba17fcd89b42e4833
Git Commit Date: 20210722
Architecture: amd64
Go Version: go1.16.6
Operating System: linux
GOPATH=
GOROOT=go

OS & Version: Linux casper 5.10.56-1-MANJARO #1 SMP PREEMPT Thu Aug 5 10:51:27 UTC 2021 x86_64 GNU/Linux

I'm was trying to follow the directions here to use geth --dev as a drop-in replacement for my ganache-cli tests as an entry to switching to geth, and while I connect to RPC and it lists the dev account with balance etc, when I submit my contract it gets promoted into the queue but gets stuck pending in the pool and never mined. This happens both with rust-web3 and truffle web3js clients.

This happens both with --dev.period=0 (default) and --dev.period=1 (I see new blocks mined, but the contract is still stuck in the pool).

rm -rf /tmp/geth_testchain/* && geth --datadir /tmp/geth_testchain/ --http --dev --verbosity 7 --miner.gasprice 1 --dev.period=1
period1.log
geth attach /tmp/geth_testchain/geth.ipc --exec "eth.pendingTransactions" (run twice a few blocks apart)
p1.txpool.log

The same thing happens with --dev.period=0, just without the extra mined blocks.

As you can see from the log it gets promoted to queued transaction, but just stays as executable in the transaction pool as new blocks are mined.

TRACE[08-13|12:47:22.000] Promoted queued transactions             count=1
DEBUG[08-13|12:47:22.000] Transaction broadcast                    txs=1 announce packs=0 announced hashes=0 tx packs=0 broadcast txs=0
INFO [08-13|12:47:22.000] Submitted contract creation              hash=0x4d8faf757d4b378a40bf868092843ef38dc306df64c79a7e7a323ac2a5ee9420 from=0xA812A32F96fe8EBAc00Dbeb0E3259b261E16172e nonce=0 contract=0xbfE7E235682D9E1C47e31A8d3Bc0c2789f7389A3 value=0
DEBUG[08-13|12:47:22.491] Transaction pool status report           executable=1 queued=0 stales=0

This seems very similar to #21951, however:

1. The logs show all forks are already starting at block# 0, which is the workaround for that issue
2. --dev.period=1 also works around that issue, but not here

[karalabe]

If you look at the genesis block

> eth.getBlock(0)
{
  baseFeePerGas: 1000000000,
  difficulty: 1,
  extraData: "0x000000000000000000000000000000000000000000000000000000000000000085d4f4e5bd07bd0caa14163d7700ebf0514f14510000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  gasLimit: 11500000,
  gasUsed: 0,
  hash: "0x4a8ac612e1e95e935b81a11db5d673ebfca1df12c68eb5f00509df8dd3818205",
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  miner: "0x0000000000000000000000000000000000000000",
  mixHash: "0x0000000000000000000000000000000000000000000000000000000000000000",
  nonce: "0x0000000000000000",
  number: 0,
  parentHash: "0x0000000000000000000000000000000000000000000000000000000000000000",
  receiptsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  size: 627,
  stateRoot: "0x109690f5f2a189f3b39f8e8935f9958eac3ce05af4799463d351c283a1bf1eb3",
  timestamp: 0,
  totalDifficulty: 1,
  transactions: [],
  transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  uncles: []
}

You'll see that baseFeePerGas is 1 gwei starting from London. Your transactions specified a gas price of 50wei, so they cannot be included in blocks until the base fee drops below that. If you raise your prices above 1 gwei, it should work again.

[domohawk]

@karalabe Thank you!

So I take it baseFeePerGas price is different from the --miner.gasprice 1 I was specifying? Or if they are the same, the protocol overrides this? If the latter, perhaps we could print a warning or error if this value is invalid?

[karalabe]

--miner.gasprice is the target the miner pushes towards, but the basefee can only change 1/1024th on every block, so it takes a while to push it down. Also the minimum is 7.

[karalabe]

Actually, it's a bit more, I think it can go /2 in 5 blocks. Either way, long way down to 7 :)

[domohawk]

Thanks for the explanation! Indeed after waiting for many blocks my initial fee of 50 does go through from pending in the original setup.