Saved Object Migrations should clean up unused mappings #67086
Labels
Feature:Saved Objects
Team:Core
Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Each time new Saved Object types are registered or existing type's mappings change Kibana will run a migration on startup to create a new index with updated mappings. However, the new index's mappings consists of the mappings for saved object types from both the old index's mappings and the updated mappings roughly something like:
const newMappings = {...outdatedMappings, ...newMappings}
.kibana/src/core/server/saved_objects/migrations/core/migration_context.ts
Lines 118 to 124 in ea7c78d
This ensure that data created by plugins that have since been disabled can be migrated to the new index without any mapping conflicts. But it means that mappings from unused Saved Object types or disabled plugins are never cleaned up so the field count will keep on slowly increasing with every migration. This also happens when a Saved Object type is "renamed", upon migration Kibana will add the mappings for the new type name, but won't remove the old mappings.
To fix this we should set the mappings of any saved object type found in the source index but not present in the upgrading node's mappings to
type: 'object', enabled: false
. This will ensure we can still write migrate any old documents, but the old types they belong to will no longer contribute to the field count.Related: #43673
The text was updated successfully, but these errors were encountered: