Pending transactions removed from txpool in geth

Question

We have been working on load-testing our private blockchain network using geth and Web3j. The transactions are sent using Web3j.

We send 100 transactions, where every block has space for about 25 of them (Because of gas limit). When transactions are received on our local node, this is printed:

TRACE[07-26|10:15:53] Pooled new future transaction            hash=20453e…f2ec96 from=0x992a03b1bb4cc56929f2d21eaf34779d0562c9a7 to=0x32f1e2e74122efd01bd666750c5afc18c4ce3f91
TRACE[07-26|10:15:53] Promoting queued transaction             hash=20453e…f2ec96
INFO [07-26|10:15:53] Submitted transaction                    fullhash=0x20453ef67cba4d3549603f7a0bc0505d170a8fc2adeac849dc1a8c2fa3f2ec96 recipient=0x32f1e2e74122efd01bd666750c5afc18c4ce3f91
TRACE[07-26|10:15:53] Broadcast transaction                    hash=20453e…f2ec96 recipients=2
DEBUG[07-26|10:15:54] Transaction pool status report           executable=43 queued=0 stales=9

When all transactions are sent, our local nodes transactionpool is txpool.status:

{
  pending: 100,
  queued: 0
}  

We then start to mine on out local node.

INFO [07-26|10:20:41] Starting mining operation 
TRACE[07-26|10:20:41] Gas limit exceeded for current block     sender=0x992a03b1bb4cc56929f2d21eaf34779d0562c9a7
INFO [07-26|10:20:41] Commit new mining work                   number=8383 txs=25 uncles=0 elapsed=18.063ms
TRACE[07-26|10:20:41] Started ethash search for new nonces     miner=0 seed=4567440808604611913
DEBUG[07-26|10:20:42] Transaction pool status report           executable=100 queued=0 stales=8
TRACE[07-26|10:20:48] Ethash nonce found and reported          miner=0 attempts=313611  nonce=4567440808604925524
INFO [07-26|10:20:48] Successfully sealed new block            number=8383 hash=774d72…ba62fc
DEBUG[07-26|10:20:48] Trie cache stats after commit            misses=11 unloads=2
INFO [07-26|10:20:48] 🔗 block reached canonical chain          number=8378 hash=81b120…f0867f
INFO [07-26|10:20:48] 🔨 mined potential block                  number=8383 hash=774d72…ba62fc
TRACE[07-26|10:20:48] Transaction failed, will be removed      hash=05c537…979f0b err="invalid nonce: have 731, expected 756"
INFO [07-26|10:20:48] Commit new mining work                   number=8384 txs=0  uncles=0 elapsed=957.166µs
TRACE[07-26|10:20:48] Propagated block                         hash=774d72…ba62fc recipients=1 duration=2562047h47m16.854s
TRACE[07-26|10:20:48] Announced block                          hash=774d72…ba62fc recipients=2 duration=2562047h47m16.8

After mining one block with 25 transactions, our txpool is now empty

{
  pending: 0,
  queued: 0
}

Only 25 of the total 100 transactions were mined, and the rest were deleted (they seem to be declared as old pending transactions). My question is then. Is this the intended behavior, or are we missing something? If it is intentional, does anyone have tips for how to solve sending multiple transactions from the same address and node?

EDIT:

We created a supervisor to check for confirmed transaction, and attempt to resend the transactions if they were lost. When resending the transactions, we receive the error:

-32000 know transaction: transaction_hash

However, when manually sending eth.getTransactionReciept(transaction_hash), null is returned.

Where is known transactions stored, and why are they not mined? (They are not in txpool)

Answer 1

the result is ok. At first, i send 110 txs, the result of txpool.status

{
    pending: 110,
    queued: 0
}

and then start mined,all of transactions were mined. As follows so the tx_pool doesn't drop any transactions. In go-ethereum source files,tx_pool.go file deal with transaction logic , some transactions will be removed if tx_pool is full that pool size over 4096+1024,the source as follows:

// If the transaction pool is full, discard underpriced transactions
if uint64(len(pool.all)) >= pool.config.GlobalSlots+pool.config.GlobalQueue {
    // If the new transaction is underpriced, don't accept it
    if pool.priced.Underpriced(tx, pool.locals) {
        log.Trace("Discarding underpriced transaction", "hash", hash, "price", tx.GasPrice())
        underpricedTxCounter.Inc(1)
        return false, ErrUnderpriced
    }
    // New transaction is better than our worse ones, make room for it
    drop := pool.priced.Discard(len(pool.all)-int(pool.config.GlobalSlots+pool.config.GlobalQueue-1), pool.locals)
    for _, tx := range drop {
        log.Trace("Discarding freshly underpriced transaction", "hash", tx.Hash(), "price", tx.GasPrice())
        underpricedTxCounter.Inc(1)
        pool.removeTx(tx.Hash())
    }
}

so there is no overflow.

Answer 2

Looks like a bug that has just been fixed: https://github.com/ethereum/go-ethereum/issues/14893