Description

I have deployed a consensus cluster with 10 orderer nodes in Hyperledger Fabric version 3.0.0-beta. Among these, orderer8, orderer9, and orderer10 are randomly started and stopped. During the experiment, I repeatedly use docker stop and docker start commands to stop and start these nodes. At any given time, only one node is stopped, with a downtime of 2 minutes, and a recovery time of 5 minutes after it is started again. During the experiment, the following panic occurs during the node recovery phase.

Upon reviewing the logs of orderer9, I found the following two log entries:

2024-11-09 09:06:46.618 UTC 164fa DEBU [orderer.consensus.smartbft.chain] getBlocksFromSyncBuffer -> Fetched and committed block [223] from cluster channel=channel1
2024-11-09 09:06:46.896 UTC 168b5 DEBU [orderer.consensus.smartbft.chain] getBlocksFromSyncBuffer -> Will fetch sequences [223-236] channel=channel1

Even after block 223 was committed, it was still selected as a block to synchronize. When the node attempted to submit block 223 again, a panic occurred.
Could the developers please help assess if such a panic represents a security risk in Fabric? I would appreciate any insights on this

Steps to reproduce

No response