transaction in pending status

[ware32]

We have several transactions in "pending" status. How can we know the reason why they are in this pending state?

Thanks

[baptiste-b-pegasys]

are you running a gas free network? do new blocks be mined?

[ware32]

is a gas free network, some transactions with nonce=0 are mined but in other we get "nonce to low"

[baptiste-b-pegasys]

I assume there is an error because the account with this error have 0 tx?

Pending is just saying that the tx is in the mempool waiting to be added in a block, and it can be added only when the nonce is matching the number of tx you have done, in order to respect the order of transactions.
GoQuorum has not change with ethereum in that respect.

[YoshihitoAso]

We have a similar problem and are currently looking into a solution.
If the transaction has a long processing time and the transaction GasLimit is set to a large value, the following error(commitInterruptNewHead) will occur and it will be stuck in the pending state.

INFO [06-21|11:39:50.025] Imported new chain segment               blocks=1 txs=0  mgas=0.000  elapsed=6.187ms     mgasps=0.000   number=20427 hash=807ae2..2e9fc7 dirty=4.77MiB
INFO [06-21|11:39:50.025] QBFT: handle final committed             address=0x47A847fbDF801154253593851aC9A2E775323534 current.round=0 current.sequence=20427 state=Committed
INFO [06-21|11:39:50.027] QBFT: initialize new round               address=0x47A847fbDF801154253593851aC9A2E775323534 current.round=0 current.sequence=20427 target.round=0 lastProposal.number=20427 lastProposal.hash=807ae2..2e9fc7
INFO [06-21|11:39:50.027] QBFT: changed state                      address=0x47A847fbDF801154253593851aC9A2E775323534 current.round=0 current.sequence=20428 old.state=Committed        new.state="Accept request"
INFO [06-21|11:39:50.028] QBFT: start new round                    address=0x47A847fbDF801154253593851aC9A2E775323534 old.round=0  old.sequence=20427 old.state=Committed        old.proposer=0x03Ee8c85944b16DFA517cB0DdeFe123c7341A534 next.round=0 next.seq=20428 next.proposer=0x35D56A7515e824BE4122f033D60063D035573a0c next.valSet="[0x03Ee8c85944b16DFA517cB0DdeFe123c7341A534 0x35D56A7515e824BE4122f033D60063D035573a0c 0x47A847fbDF801154253593851aC9A2E775323534 0xc25d04978fd86ee604FeB88f3C635D555eB6D42D]" next.size=4 next.IsProposer=false
INFO [06-21|11:39:50.044] Aborting transaction processing due to 'commitInterruptNewHead', elapsed time=954.247024ms
INFO [06-21|11:39:50.047] Submitted transaction                    hash=0x362d014bc51e7b344378d03fed12925c8c76caddf280515114410ae25fdb00e1 from=0xA2ab4ae7e48A0f6AFd66B4e9d03fc605aB1de23C nonce=0  recipient=0xc6DA053780Dc920EFFe2B7bc5b6dF4015960E837 value=0
INFO [06-21|11:39:50.065] Commit new mining work                   number=20428 sealhash=96200e..62b131 uncles=0 txs=0  gas=0          fees=0 elapsed=18.269ms
INFO [06-21|11:39:50.118] Setting new local account                address=0xeDeA99399f361aE7abb268a9cCb794922d64AE74
INFO [06-21|11:39:50.133] Submitted transaction                    hash=0xb00218488412d79957b929c1545e5be3579716d51f6b058a30eb91c02a9d7338 from=0xeDeA99399f361aE7abb268a9cCb794922d64AE74 nonce=0  recipient=0xc6DA053780Dc920EFFe2B7bc5b6dF4015960E837 value=0
INFO [06-21|11:39:50.161] Setting new local account                address=0xefB808a0D5730cC3622023cB07F5D5555dB796C7

Related issues: BoostryJP/quorum#40

[ware32]

I assume there is an error because the account with this error have 0 tx?

Pending is just saying that the tx is in the mempool waiting to be added in a block, and it can be added only when the nonce is matching the number of tx you have done, in order to respect the order of transactions. GoQuorum has not change with ethereum in that respect.

The account with this error has more than 0 tx, our consensus protocol is RAFT

[hhsel]

We have a similar problem and are currently looking into a solution. If the transaction has a long processing time and the transaction GasLimit is set to a large value, the following error(commitInterruptNewHead) will occur and it will be stuck in the pending state.

INFO [06-21|11:39:50.025] Imported new chain segment               blocks=1 txs=0  mgas=0.000  elapsed=6.187ms     mgasps=0.000   number=20427 hash=807ae2..2e9fc7 dirty=4.77MiB
INFO [06-21|11:39:50.025] QBFT: handle final committed             address=0x47A847fbDF801154253593851aC9A2E775323534 current.round=0 current.sequence=20427 state=Committed
INFO [06-21|11:39:50.027] QBFT: initialize new round               address=0x47A847fbDF801154253593851aC9A2E775323534 current.round=0 current.sequence=20427 target.round=0 lastProposal.number=20427 lastProposal.hash=807ae2..2e9fc7
INFO [06-21|11:39:50.027] QBFT: changed state                      address=0x47A847fbDF801154253593851aC9A2E775323534 current.round=0 current.sequence=20428 old.state=Committed        new.state="Accept request"
INFO [06-21|11:39:50.028] QBFT: start new round                    address=0x47A847fbDF801154253593851aC9A2E775323534 old.round=0  old.sequence=20427 old.state=Committed        old.proposer=0x03Ee8c85944b16DFA517cB0DdeFe123c7341A534 next.round=0 next.seq=20428 next.proposer=0x35D56A7515e824BE4122f033D60063D035573a0c next.valSet="[0x03Ee8c85944b16DFA517cB0DdeFe123c7341A534 0x35D56A7515e824BE4122f033D60063D035573a0c 0x47A847fbDF801154253593851aC9A2E775323534 0xc25d04978fd86ee604FeB88f3C635D555eB6D42D]" next.size=4 next.IsProposer=false
INFO [06-21|11:39:50.044] Aborting transaction processing due to 'commitInterruptNewHead', elapsed time=954.247024ms
INFO [06-21|11:39:50.047] Submitted transaction                    hash=0x362d014bc51e7b344378d03fed12925c8c76caddf280515114410ae25fdb00e1 from=0xA2ab4ae7e48A0f6AFd66B4e9d03fc605aB1de23C nonce=0  recipient=0xc6DA053780Dc920EFFe2B7bc5b6dF4015960E837 value=0
INFO [06-21|11:39:50.065] Commit new mining work                   number=20428 sealhash=96200e..62b131 uncles=0 txs=0  gas=0          fees=0 elapsed=18.269ms
INFO [06-21|11:39:50.118] Setting new local account                address=0xeDeA99399f361aE7abb268a9cCb794922d64AE74
INFO [06-21|11:39:50.133] Submitted transaction                    hash=0xb00218488412d79957b929c1545e5be3579716d51f6b058a30eb91c02a9d7338 from=0xeDeA99399f361aE7abb268a9cCb794922d64AE74 nonce=0  recipient=0xc6DA053780Dc920EFFe2B7bc5b6dF4015960E837 value=0
INFO [06-21|11:39:50.161] Setting new local account                address=0xefB808a0D5730cC3622023cB07F5D5555dB796C7

Related issues: BoostryJP/quorum#40

In this case I have found that setting emptyblockperiodseconds larger than blockperiodseconds alleviates the issue.
If there are too many time-consuming transactions in the pending pool, the proposer tries to sequentially process "all" of them at once in the specified block time and just cannot finish processing in time.
As a result, no transactions are reported to the consensus layer, and an empty block is proposed (the exception where a node does not try to process all of the transaction in the pool is when the total amount of gas consumed reaches the block gas limit, so limiting block gas limit to moderate value is another solution).

After the cluster approved the empty block, notification that a new block arrives is sent to the miner thread and the "stale" mining process that could not be finished in time is aborted forcibly (commitInterruptNewHead is the one).
Since validator nodes tend to share the same transactions set, the next proposer cannot process those transactions in time too, producing an empty block again.
In this way the cluster goes into an "empty block proposal loop" and no transactions will be included in blocks, until you manually clear the pool.

emptyblockperiodseconds can relieve this problem because it decides when to propose an empty block if there are no transactions reported to the consensus layer within blockperiodseconds.
So if you set emptyblockperiodseconds to 2x of blockperiodseconds, for example, you have 2x time to process transactions when a node cannot process transactions within blockperiodseconds.

The obvious drawbacks are, however, it makes block period unstable when on high load, which may have implications on user experience, and, more importantly, currently setting emptyblockperiodseconds may lead to a chain fork, as reported in #1630, which is why I posted that issue (I just wanted to enable emptyblockperiodseconds to prevent this high-load problem.)

[YoshihitoAso]

@hhsel , thank you for your comment.

However, the problem of my commented transaction being stuck in pending state also occurs if you don't use emptyBlockPeriodSeconds.

Simply, it occurs when a large number of transactions with high load accumulate in the txpool in a short period of time.
In the consortium chain, there are various ways to prevent such transactions, so I don't think it's a big problem, but we would like to solve the problem in the near future.

There may be other examples of transactions being stuck in pending state besides the one I commented on. I have just shared our problem.