Transaction in memory pool can not be broadcast

[cloud8little]

Describe the bug
Very randomly when sending massive rpc (sendtoaddress) requests, there may be one or two txs won't be dealt with and always stay in the mempool.

Backgroud:
More information: #1756 (comment)

To Reproduce
Steps to reproduce the behavior: (PLEASE note this can only be reproduced randomly)

1. Prepare a wallet, here I use wallet_1.json, actually it is my CN wallet. with one standard address, one multisig address(m=1); initial asset is

neo> list asset
Nc56Zrq72VN9Xr6wo3HyFn3oFZUvoYQJtj
NEO: 49990000
GAS: 47.3869169

Ncu47NyTJLJPEFi859gmuqQ8fPPt1AVwHX
NEO: 50000000
GAS: 29930613.53667778

----------------------------------------------------
Total:   NEO: 99990000    GAS: 29930660.92359468

NEO hash: 0xde5f57d430d3dece511cf975a8d37848cb9e0525
GAS hash: 0x668e0c1f9d7b70a99dd9e06eadd4c784d641afbc

2. use Jmeter to run parallel sendtoaddress requests;

{
  "jsonrpc": "2.0",
  "method": "sendtoaddress",
  "params": ["0x668e0c1f9d7b70a99dd9e06eadd4c784d641afbc", "NSJZ186oShqryg6D8xfcv5Te5GhQ8GFno9", 10.23456789],
  "id": 1
}

3. when the requests are not finished yet, stop the task.

4. then I getrawmempool from the node, there are 9 txs in the pool for my case.
   

Expected behavior
tx should be broadcast to the CN node and removed from the mempool.

Platform:

• OS: Windows 10 x64

[Tommo-L]

After investigation, this is not a bug, but a problem caused by the operation flow.

Preconditions：

1. ② happen before ③
2. After one block, the balance is added. (Then the old txs with insufficient balance, can be valid now)

Why consensus node waits a lot of time to receive the tx, which reboadcasted by Neo-CLI.

Once transaction received, the transaction will be added in knowHashes of TaskManager. Cleanup operations are performed only when knowHashes are full.

[cloud8little]

Close because it is a mechanism problem.