Raft consensus failure preventing leader election in Consul cluster

When a Consul cluster fails to establish a leader, the agent logs often indicate that the Raft protocol cannot achieve a majority. This behavior typically occurs in environments where nodes are reachable but remain in a follower or candidate state indefinitely, despite valid connectivity between the configured cluster members.

The challenge lies in distinguishing between transient network latency and a permanent failure caused by stale state files or mismatched bootstrap expectations. While the logs show repeated attempts to reach a quorum, they do not always explicitly state whether the failure is due to a specific network partition or a configuration mismatch in the join-list.

What specific log patterns differentiate a network-induced partition from a configuration-based failure to reach a quorum? How can one determine if a node is failing to join due to an outdated local raft index versus a mismatch in the expected cluster size?