Storage mining transactions are missing or not submitted

[syntrust]

System information

• branch: tm_w3q_sstorage_miner_debug
• testnet: (https://testnet.web3q.io:8545)

Expected behavior

Mining txs should be submitted and mined successfully and periodically.

Actual behavior

Shortly after the node starts, a mining tx is submitted sometimes with the following log.

WARN [04-20|09:41:02.800] worker::submitMinedResult() >>>>>> estimate gas Succeed <<<<<< block timestamp=1,681,983,645 minedTs=1,681,983,604
WARN [04-20|09:41:02.800] submitMinedResult                        shard idx=0 tx hash=66c0df..c4dced kv idx list="[639 845 817 523 167 547 770 448 591 406 321 383 558 155 201 712]" chunk idx list="[18 14 18 2 2 18 28 15 18 27 9 4 26 11 30 6]"
Submit Mine Result txHash: 0x66c0df0fcc522c4479fbb7496e52399a305eebd68b8408bf3f7ffc0f18c4dced

1. The submission behavior when starting the node is not always expectable.
2. When the above submission log appears, the tx cannot be found:

   
   > eth.getTransaction("0x66c0df0fcc522c4479fbb7496e52399a305eebd68b8408bf3f7ffc0f18c4dced")
   null

3. The mining hash is updated in the mining info, meaning one mining tx succeeded, but this behavior cannot be reproduced.
```sh
[
  '0x0102107efadcb186acdf5f826536aafb763d18bf77b4b0591c28b13832d2e758',
  BigNumber { value: "1681976129" },
  BigNumber { value: "100" },
  BigNumber { value: "1" },
  miningHash: '0x0102107efadcb186acdf5f826536aafb763d18bf77b4b0591c28b13832d2e758',
  lastMineTime: BigNumber { value: "1681976129" },
  difficulty: BigNumber { value: "100" },
  blockMined: BigNumber { value: "1" }
]

Steps to reproduce the behavior

Restart the node with the following sstorage params

--sstorage.shard=128k,0 \
--sstorage.file="/root/data/node/ss0.dat" \
--sstorage.mine=true \ 
--sstorage.minercontract="0x0000000000000000000000000000000003330001" \ 
--sstorage.txsigner=0x2cff0b8e36522eba76f6f5c328d58581243882e4 \ 

[ping-ke]

We use the API backend to send transactions, so the node will broadcast to other nodes. the fix is as follows. err = w.apiBackend.SendTx(ctx, signedTx) This will be fixed https://github.com/QuarkChain/go-ethereum/pull/131.

[syntrust]

With commit 39d81ce, it only starts mining after a syncing process. If stop and start immediately, it will not start mining.

[syntrust]

Won't fix because:

1. It only happens when the node is both tendermint validator and a storage miner.
2. Workaround is to wait for a min before starting.

Suggest the validator and storage miner run separately.