[SO Migration] Improve the alias detection

[pgayvallet]

Currently, the system will attempt to try the migration if either the versionAlias or the currentAlias is missing.

In theory, as both alias are created at the same time atomically during the MARK_VERSION_INDEX_READY step, they should both be either existing or non-existing.

However, in some case of migration failures requiring manual intervention, a human mistake may cause to have only one or the other to be manually created.

If the versionAlias is missing, the migration system will try to attempt a migration from the current index to itself (e.g .kibana_7.14.0 to .kibana_7.14.0). If this has no effect on the data integrity, it will fail during the later steps, as we would be write-blocking what we consider to be the source index.

We should improve the checks we're doing here:

kibana/src/core/server/saved_objects/migrationsv2/model/model.ts

Lines 65 to 72 in 6b26949

	if (
	// `.kibana` and the version specific aliases both exists and
	// are pointing to the same index. This version's migration has already
	// been completed.
	aliases[stateP.currentAlias] != null &&
	aliases[stateP.versionAlias] != null &&
	aliases[stateP.currentAlias] === aliases[stateP.versionAlias]
	) {

To either

• fail the migration if ONLY the versionAlias is missing
• be 'smart' and only create this versionAlias and then continue to OUTDATED_DOCUMENTS_SEARCH_OPEN_PIT as done when both aliases are present.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[lukeelmers]

+1 to the "be smart" approach.

If we can avoid introducing another failure scenario without increasing complexity in a significant way, it feels worth it to me.

[afharo]

This failed test might be related: #97942

[afharo]

Also this other failed test might be related: #98463

[afharo]

Bumping this issue for discussion. I'm reviewing some failed tests and they seem to be related to this issue. @elastic/kibana-core should we increase the priority on this one?

[rudolf]

@afharo I believe these failed errors come from esArchiver, left a comment #121050 (comment)