[BUG] homepage doc migration issue

[bandinib-amzn]

Describe the bug

During migration I'm getting Detected mapping change in \"properties.homepage\" error.

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior A clear and concise description of what you expected to happen.

OpenSearch Version 2.13

Dashboards Version 2.13

Plugins

Please list all plugins currently enabled.

Screenshots

If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

• OS: [e.g. iOS]
• Browser and version [e.g. 22]

Additional context

Add any other context about the problem here.

[ananzh]

I produced the issue. We do see a warning Detected mapping change in "properties.homepage but it won't block the migration as long as there is no mapping conflicts in user's kibana index

async runMigration() {
        if (await requiresMigration(context)) {
          return migrateIndex(context);
        }

        return { status: 'skipped' };
      },

migrate success from 2.11 to 2.13 even with the msg

server    log   [18:52:50.742] [info][savedobjects-service] Waiting until all OpenSearch nodes are compatible with OpenSearch Dashboards before starting saved objects migrations...
server    log   [18:52:50.778] [info][savedobjects-service] Starting saved objects migrations
server    log   [18:53:49.100] [info][savedobjects-service] Detected mapping change in "properties.homepage"
server    log   [18:53:53.804] [info][savedobjects-service] Creating index .kibana_2.
server    log   [18:53:57.150] [info][savedobjects-service] Migrating .kibana_1 saved objects to .kibana_2
server    log   [18:53:57.559] [info][savedobjects-service] Pointing alias .kibana to .kibana_2.
server    log   [18:53:58.589] [info][savedobjects-service] Finished in 4792ms.
server    log   [18:54:24.729] [warning][cross-compatibility-service] Starting cross compatibility service
server    log   [18:54:24.729] [info][plugins-system] Starting [38] plugins: [usageCollection,opensearchDashboardsUsageCollection,opensearchDashboardsLegacy,mapsLegacy,share,opensearchUiShared,legacyExport,embeddable,expressions,data,savedObjects,home,apmOss,dashboard,visualizations,visTypeVega,visTypeTimeline,visTypeTable,visTypeMarkdown,visBuilder,visAugmenter,tileMap,regionMap,inputControlVis,visualize,management,indexPatternManagement,advancedSettings,console,dataExplorer,charts,visTypeVislib,visTypeTimeseries,visTypeTagcloud,visTypeMetric,discover,savedObjectsManagement,bfetch]

https://github.com/opensearch-project/OpenSearch-Dashboards/assets/79961084/2cf7b6ab-9d63-4d99-8cae-4a6fc30af8fc

compared with revert home https://github.com/opensearch-project/OpenSearch-Dashboards/pull/6065. Here the migration is skipped so we can't detect any mapping conflict. Though migration success, it is a false positive.

https://github.com/opensearch-project/OpenSearch-Dashboards/assets/79961084/fccfa454-6eca-4fa6-8903-9e43d019e0b6

[ananzh]

[Issue]

In OpenSearch Dashboards, saved object migrations ensure that the data structures (mappings) used by the application are up-to-date and consistent with the current codebase.

When a migration is triggered, the system checks for any changes in the index mappings. If a change is detected, it attempts to create a new index and migrate the saved objects. However, if there are any broken documents or conflicting mappings in the existing index, this process can fail, resulting in errors like resource_already_exists_exception when the system attempts to create an index that already exists.

In our case, a change to the properties.homepage mapping is causing the migration to be triggered repeatedly, which can lead to such errors. This issue can be particularly problematic for customers, as it may disrupt their workflows and data operations.

[Tmp Solution]

The objective of the temporary solution is to unblock the migration process while still allowing the system to detect and respond to other critical mapping changes. However, it is important to note that skipping this migration might allow broken documents to be migrated, which can have some impact.

We modify the requiresMigration function to ignore changes to the properties.homepage mapping specifically, changing from if (diffResult) to if (diffResult && diffResult.changedProp !== "properties.homepage"). This way, the migration process won't be triggered by this particular change, but it will still respond to other mapping changes that might require a migration.

[ashwin-pc]

So the TLDR here is that whenever mappings change during a version upgrade a migration is triggered, and if your .kibana index was corrupted, the migration failed. And the reason we dont see this as often is because migrations havent been triggered in previous OSD upgrades because no mapping changed.

What would happen if the mapping didnt change? would the migration still fail? if the changed mapping the only reason the upgrade failed?