When a network split creates a split-brain scenario, most systems try to resolve it automatically through consensus protocols. Vitess takes a different path…
It is deliberately conservative about what it will do automatically.
Vitess does have an automated fault detection and repair component called VTOrc. It performs automatic failover, but only when it can do so safely under the configured durability policy. When it cannot guarantee a safe promotion, it will not act.
The reason comes down to what you are optimizing for.
Vitess uses semi-synchronous replication with the fallback to async replication. This means the primary will stall rather than silently accept writes that have not been acknowledged by at least one replica.
The tradeoff is deliberate: stalling is recoverable, data divergence is not.
During a partition, automated resolution has to make decisions with incomplete information. It might promote a replica to primary while the original is still running, resulting in two nodes independently accepting writes. When the network heals, you now have conflicting write histories to reconcile, not just a connectivity one.
When VTOrc cannot verify that it can perform a lossless failover, it will refuse to promote a new primary unless you explicitly override the safety checks. Queries depending on that primary may fail or stall, but Vitess will not make a decision that could corrupt the data.
When VTOrc cannot act safely, it steps aside, and a human decides when and how to recover.
The interesting engineering lesson here is that “act only when you can act safely” is sometimes the most defensible design choice.
Not every failure mode (always) needs an automated fix.