-
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
Possible race condition with migrations #101654
Comments
Pinging @elastic/kibana-core (Team:Core) |
Leaning towards this not so much being an issue as it is a problem with our functional tests. Turns out that some of our archives are old enough they need to be processed through the legacy migration, which is actually determined by it not being an alias. Additionally, when importing another esArchive we are not currently clearing out all aliases which seems to be an issue. |
Same as elastic#101950 - these archives are causing issues with a non-oss build elastic#101654 Last remaining fix for elastic#101118 Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
…101992) Same as elastic#101950 - these archives are causing issues with a non-oss build elastic#101654 Last remaining fix for elastic#101118 Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
@tylersmalley Any updates here? I want to make sure that we get ahead of any races if we do indeed have any. |
I don't think this is still an issue. |
The backport of using the default distribution for all functional tests #94968 created many failures which were not seen during the original PR against master. These failures happen during the loading of
esArchive
data containing a.kibana
index. During an investigation with @TinaHeiligers we determined that it appeared isolated to archives that were not utilizing an alias and directly creating a.kibana
index and running migrations on it. The long-term fix here is to remove any usage ofesArchiver
with the saved object's indices and instead use the import API. This work has already begun, but it's going to take time and the concern here is this might be an actual issue. I think we need to understand if that is the case, or it's that we're doing something inesArchiver
which is unsupported.Minimal reproduction:
7.x
branch (current SHA: 2e3b200)test/functional/config.js
, removing the--oss
Kibana server argumentesArchive
which writes to the Kibana archive. Downloading the archive as there is a backport pending updating this mapping to use an alias. The esArchive this is taken from is the deprecations_service archive.wget -qO- https://gist.github.com/tylersmalley/cffdf820615ef661eec666e3fb1a1b96/archive/7b260c33ab207026b3a3782741a9449358707e2c.zip | jar xvf /dev/stdin
node scripts/functional_tests_server.js --config test/functional/config.js
The archive might need loaded a few times, as the failure doesn't appear consistent.
The failure case is the migration fails and crashes the server.
#101537 was created in hopes of circumventing this issue for now in the functional tests by using an alias to avoid the legacy migration step - however, that seems to have now created a similar failure on master, which is also flaky.
https://kibana-ci.elastic.co/job/elastic+kibana+master/14654/execution/node/794/log/
The text was updated successfully, but these errors were encountered: