The private chain deployed the master and backup SR nodes and an error of "Dup block produced" was reported

[jakamobiii]

System information

Java-tron version: v4.7.4
OS & Version: Linux & macOS

Expected behavior

"Dup block produced" error should not be reported.

Actual behavior

When the private chain deploys the master and backup SR nodes, a "Dup block produced" error is reported. Does this have any impact?

18:35:50.785 WARN  [peerClient-20] [consensus](StateManager.java:101) Dup block produced: BlockCapsule 
[ hash=00000000000003a937ef9829a14b3b26f5fae0baec0b04163eb8a56bfecf480c
number=937
parentId=00000000000003a8fa01cace0d4826ba43c8f2ea99ed7c56a6998bf54cbc02bd
witness address=414595827b70d21454b39ab60bf13291dae8dc0878
generated by myself=false
generate time=2024-04-23 18:39:09.0
account root=0000000000000000000000000000000000000000000000000000000000000000
txs are empty
]

Frequency

1 time

[zeusoo001]

@jakamobiii This may be due to the MASTER/SLAVER switchover, resulting in two blocks. Can you provide detailed logs?

[jakamobiii]

@zeusoo001 Sorry, the log has been deleted. Will the two blocks produced be saved on the chain? Will it cause data inconsistency?

[zeusoo001]

@jakamobiii Only one block will be saved on the chain, which will not affect data consistency.

[jwrct]

@jakamobiii Although logs are not available, could you provide some additional information, such as whether there were any operations before the warning log was printed, or if you saw any master-slave switching during block production when you previously viewed the logs. This will help to identify potential issues.

[jwrct]

@zeusoo001 Have you analyzed what scenarios might trigger such a warning log?

[zeusoo001]

@jwrct There are two scenarios that may cause this problem. One is that the master-slave heartbeat breaks and both enter the master state. However, there is a concurrency problem between the master-slave switching and the block production thread.

State state = stateManager.getState();
    if (!State.OK.equals(state)) {
      return state;
    }

    dposService.getBlockHandle().setBlockWaitLock(true);
    try {
      synchronized (dposService.getBlockHandle().getLock()) {

Before acquiring the lock, it is in the master state. After acquiring the lock, it may enter the slave state. Because there is no status check after acquiring the lock, blocks are generated directly, and the probability is very low.

[zeusoo001]

Fixed in this PR: #5833