-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tag invalid objects instead of failing migrations #64885
Conversation
Pinging @elastic/kibana-platform (Team:Platform) |
valid: { | ||
type: 'boolean', | ||
}, | ||
invalid_attributes: { | ||
enabled: false, // Don't index invalid attributes | ||
type: 'object', | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we nest all these new fields into a single nested field such as migration
or status
? It may be a little cleaner?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been thinking about this, it feels like something as important as the status: 'invalid' | 'corrupt' | 'valid'
should be at the top-level rather than hidden under another layer.
I found the |
That does sound useful. I wonder how much work it really would be to define schema (with kbn/config-schema) for all SO types. |
You're thinking about automated schema generation from the mapping, or manual schema definition by the owners here? |
💔 Build Failed
Failed CI StepsTest FailuresKibana Pipeline / kibana-xpack-agent / Chrome X-Pack UI Functional Tests.x-pack/test/functional/apps/rollup_job/tsvb·js.rollup app tsvb integration create rollup tsvbStandard Out
Stack Trace
Kibana Pipeline / kibana-xpack-agent / Chrome X-Pack UI Functional Tests.x-pack/test/functional/apps/rollup_job/tsvb·js.rollup app tsvb integration create rollup tsvbStandard Out
Stack Trace
History
To update your PR or re-run it, just comment with: |
I think a manual schema would be the most useful. I think adding definitions would be fairly straight-forward, the open question up until now was, what do we do when an object in the index is invalid. But it doesn't have to block on this PR, we could validate all incoming objects at the SavedObjectsRepository but exclude validation when reading from the index. |
From Section 5.5 in the "Improve saved object migrations RFC" #66056
|
Summary
Implements step 1 from #55406
TODO:
{7.6.1: migrationTransformBuggyFn}
->{7.6.2: migrationTransformFixedFn}
Open questions:
migrate711
->migrate730
->migrate760
. If there's a bug inmigrate711
how do we release a fix so that invalid documents are automatically recovered in future versions?migrate711
and then release a new no-op migration likemigrateNoop761
. 👎 Causes a migration for all users even if they don't have invalid data.fixInvalid761
that only matches migrationVersion of invalid documents. Unclear exactly how this would work. For now, set{migrationVersion: {['invalid:'+type]: ${currentKibanaVersion}}}
Checklist
Delete any items that are not applicable to this PR.
For maintainers