[Lock Manager] Handle alias resolution when checking lock index mappings #244559

SrdjanLL · 2025-11-27T16:22:50Z

Relates to: https://github.com/elastic/sdh-kibana/issues/5923

Summary

Handle Lock Manager's alias resolution during migration:
- when checking lock index mappings
- in cases when concrete index creation is attempted, but the name is already used as alias

Testing

New unit tests:

yarn test:jest src/platform/packages/shared/kbn-lock-manager/src/setup_lock_manager_index.test.ts

Updated integration tests:

node scripts/functional_tests_server --config x-pack/solutions/observability/test/api_integration_deployment_agnostic/configs/stateful/oblt.ai_assistant.stateful.config.ts

# Then run in a separate terminal:
node scripts/functional_test_runner --config x-pack/solutions/observability/test/api_integration_deployment_agnostic/configs/stateful/oblt.ai_assistant.stateful.config.ts --grep="LockManager"

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

Unit or functional tests were updated or added to match the most common scenarios

Identify risks

This PR aims to mitigate risks that occur during migration. The implementation makes certain assumptions on the way migration tooling functions. In the unlikely events of that changing, the logic may need to be revisited

Reviewer notes

AI assisted coding with Cursor and Claude 4.5 Opus:
- Plan generation (to help cover all relevant places
- Unit test generation

src/platform/packages/shared/kbn-lock-manager/src/setup_lock_manager_index.ts

sorenlouv · 2025-11-28T08:29:00Z

...loyment_agnostic/apis/ai_assistant/distributed_lock_manager/distributed_lock_manager.spec.ts

      });
+
+      describe('when lock index is accessed via alias (simulating reindexed scenario)', () => {
+        const reindexedIndexName = `${LOCKS_CONCRETE_INDEX_NAME}-reindexed-for-10`;


Thanks for covering this scenario!

sorenlouv · 2025-11-28T08:31:33Z

...loyment_agnostic/apis/ai_assistant/distributed_lock_manager/distributed_lock_manager.spec.ts

+          // This should NOT throw "Cannot destructure property 'mappings' of 'res[LOCKS_CONCRETE_INDEX_NAME]' as it is undefined"
+          try {
+            await setupLockManagerIndex(es, logger);
+          } catch (error) {
+            expect().fail(
+              `setupLockManagerIndex should not throw when index is accessed via alias, but got: ${error.message}`
+            );
+          }


I don't understand this test. Do you expect it to throw or not?
The comment seems to say that it should not throw, but the code assumes that it throws because the expectation is in the catch block

Ah, I never used expect().fail() but I suppose that fails the test if it reaches the catch block

btw. if the index ${LOCKS_CONCRETE_INDEX_NAME}-reindexed-for-10 exists, and setupLockManagerIndex is called, will that create a new index called ${LOCKS_INDEX_ALIAS}-000001?

Based on this I think it will:

kibana/src/platform/packages/shared/kbn-lock-manager/src/setup_lock_manager_index.ts

Line 92 in 75d918c

await esClient.indices.create({ index: LOCKS_CONCRETE_INDEX_NAME });

Can you double check if that's the case? Because that could be problematic

Ah, I never used expect().fail() but I suppose that fails the test if it reaches the catch block

Yeah.. it's kinda like re-throwing an exception and enriching it with more context. Happy to remove and just let fail if that's not our common practice.

btw. if the index ${LOCKS_CONCRETE_INDEX_NAME}-reindexed-for-10 exists, and setupLockManagerIndex is run, will that create a new index called ${LOCKS_INDEX_ALIAS}-000001?

About this, you're good to question this and it's what I've noticed when running the integration tests (hence why I left the PR still in draft).

After resolving the issue with mappings, I found the integ tests still to fail with invalid_index_name_exception:

Error: setupLockManagerIndex should not throw when index is accessed via alias, but got: invalid_index_name_exception Root causes: invalid_index_name_exception: Invalid index name [.kibana_locks-000001], already exists as alias

I guess this happens within the migration tooling during index migration (aliasing on the concrete index name) and will affect the index creation as you mention.

I got around this locally by catching the exception and skipping creation similarly to resource_already_exists_exception, as a usable alias already exists? Does that workaround sound good to you?

Happy to remove and just let fail if that's not our common practice.

No, I like it 👍

I got around this locally by catching the exception and skipping creation similarly to resource_already_exists_exception, as a usable alias already exists? Does that workaround sound good to you?

Yes, I think if an alias exists and it points to a concrete index we should handle (swallow) the error, and skip error creation

Great, thanks for confirming - I've added that change already (might just get lost in all the auto-generated moon changes 🌔 )

…anager_index.ts Co-authored-by: Søren Louv-Jansen <[email protected]>

…e migration)

elasticmachine · 2025-11-28T10:24:44Z

Pinging @elastic/obs-ai-team (Team:obs-ai)

SrdjanLL · 2025-11-28T10:26:56Z

src/platform/packages/shared/kbn-lock-manager/src/setup_lock_manager_index.ts

+    // Handle the case where the index name already exists as an alias (e.g., after a reindex operation during cluster upgrade)
+    const isIndexNameExistsAsAliasError =
+      error instanceof errors.ResponseError &&
+      error.body.error.type === 'invalid_index_name_exception';
+
+    if (isIndexAlreadyExistsError || isIndexNameExistsAsAliasError) {


@sorenlouv I applied the changes I suggested for what you mentioned in this comment. Thought it's easier to iterate on it if it's seen in the works (and I no longer see the integ test errors). Let me know what you think!

Does the existing integration test cover this? Does it fail without this change? (it should)

Does it fail without this change? (it should)

Yes, confirmed it fails with:

2) Stateful Observability - Deployment-agnostic AI Assistant API integration tests observability AI Assistant LockManager index assets when lock index is accessed via alias (simulating reindexed scenario) should successfully acquire a lock when index is accessed via alias: ResponseError: invalid_index_name_exception Root causes: invalid_index_name_exception: Invalid index name [.kibana_locks-000001], already exists as alias

btw. not needed now, but I wonder if ensureTemplatesAndIndexCreated should create the alias .kibana_locks pointing to .kibana_locks-000001.
And if the alias (or index) already exists we do nothing.

But we'd have to consider if this is fully backwards compatible.

Sounds like a good, future-proof, suggestion, but because of the backwards compatibility considerations and my (just acquired) familiarity with the lock manager, I'd suggest to leave it out of this PR and track as a follow up?

If you're feeling strongly, happy to figure out, but may need more heads as I'm rotating out from SDH and we'll be focusing on AB offsite next week.

No, I agree. Let's leave that out

elasticmachine · 2025-11-28T10:58:07Z

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)

sorenlouv

Thank you so much! Great improvement

kibanamachine · 2025-12-02T10:28:39Z

Starting backport for target branches: 8.19, 9.1, 9.2

https://github.com/elastic/kibana/actions/runs/19855390956

elasticmachine · 2025-12-02T10:29:05Z

💚 Build Succeeded

Buildkite Build
Commit: e521b62

Metrics [docs]

✅ unchanged

History

💚 Build #366789 succeeded 3ac5d51
💔 Build #366719 failed 790cc1c
💔 Build #366670 failed 614071f
💔 Build #366656 failed b95fe4a
💔 Build #366647 failed 9fad13a

kibanamachine · 2025-12-02T10:36:48Z

💔 All backports failed

Status	Branch	Result
❌	8.19	Backport failed because of merge conflicts
❌	9.1	Backport failed because of merge conflicts
❌	9.2	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 244559

Questions ?

Please refer to the Backport tool documentation

…ngs (elastic#244559) Relates to: elastic/sdh-kibana#5923 ## Summary - Handle Lock Manager's alias resolution during migration: - when checking lock index mappings - in cases when concrete index creation is attempted, but the name is already used as alias ## Testing New unit tests: ```bash yarn test:jest src/platform/packages/shared/kbn-lock-manager/src/setup_lock_manager_index.test.ts ``` Updated integration tests: ```bash node scripts/functional_tests_server --config x-pack/solutions/observability/test/api_integration_deployment_agnostic/configs/stateful/oblt.ai_assistant.stateful.config.ts # Then run in a separate terminal: node scripts/functional_test_runner --config x-pack/solutions/observability/test/api_integration_deployment_agnostic/configs/stateful/oblt.ai_assistant.stateful.config.ts --grep="LockManager" ``` ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### Identify risks - This PR aims to mitigate risks that occur during migration. The implementation makes certain assumptions on the way migration tooling functions. In the unlikely events of that changing, the logic may need to be revisited ### Reviewer notes - AI assisted coding with Cursor and Claude 4.5 Opus: - Plan generation (to help cover all relevant places - Unit test generation --------- Co-authored-by: Søren Louv-Jansen <[email protected]> Co-authored-by: kibanamachine <[email protected]>

kibanamachine · 2025-12-03T10:48:53Z

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create automatically backports add a backport:* label or prevent reminders by adding the backport:skip label.
You can also create backports manually by running node scripts/backport --pr 244559 locally
cc: @SrdjanLL

Handle alias resolution when checking lock index mappings

9d892a1

SrdjanLL added backport:version Backport to applied version labels Team:obs-ai Observability AI team labels Nov 27, 2025

sorenlouv reviewed Nov 27, 2025

View reviewed changes

src/platform/packages/shared/kbn-lock-manager/src/setup_lock_manager_index.ts Outdated Show resolved Hide resolved

sorenlouv reviewed Nov 27, 2025

View reviewed changes

src/platform/packages/shared/kbn-lock-manager/src/setup_lock_manager_index.ts Outdated Show resolved Hide resolved

sorenlouv reviewed Nov 28, 2025

View reviewed changes

SrdjanLL and others added 4 commits November 28, 2025 10:05

Update src/platform/packages/shared/kbn-lock-manager/src/setup_lock_m…

6cade91

…anager_index.ts Co-authored-by: Søren Louv-Jansen <[email protected]>

Update src/platform/packages/shared/kbn-lock-manager/src/setup_lock_m…

97d75b8

…anager_index.ts Co-authored-by: Søren Louv-Jansen <[email protected]>

Handle the case when concrete index name is already used as alias (i.…

f385373

…e migration)

Update error flag variable name

9fad13a

SrdjanLL added v9.2.1 v9.2.2 release_note:fix labels Nov 28, 2025

SrdjanLL marked this pull request as ready for review November 28, 2025 10:24

SrdjanLL requested review from a team as code owners November 28, 2025 10:24

SrdjanLL commented Nov 28, 2025

View reviewed changes

Changes from node scripts/lint_ts_projects --fix

b95fe4a

elastic-vault-github-plugin-prod bot requested review from a team as code owners November 28, 2025 10:37

botelastic bot added the Team:obs-ux-management label Nov 28, 2025

SrdjanLL force-pushed the sdh-lock-manager-alias-handling branch from 614071f to b95fe4a Compare November 28, 2025 11:56

Merge branch 'main' into sdh-lock-manager-alias-handling

a22de18

SrdjanLL removed request for a team November 28, 2025 11:57

kibanamachine and others added 2 commits November 28, 2025 12:16

Changes from node scripts/regenerate_moon_projects.js --update

62e2b0a

Fix check types

790cc1c

Fix MappingTypeMapping import path

3ac5d51

SrdjanLL added v8.19.8 v9.1.8 labels Nov 28, 2025

sorenlouv approved these changes Nov 28, 2025

View reviewed changes

SrdjanLL removed the v9.2.1 label Dec 2, 2025

Merge branch 'main' into sdh-lock-manager-alias-handling

e521b62

SrdjanLL enabled auto-merge (squash) December 2, 2025 08:23

SrdjanLL merged commit 6b81b37 into elastic:main Dec 2, 2025
12 checks passed

kibanamachine added the v9.3.0 label Dec 2, 2025

kibanamachine added the backport missing Added to PRs automatically when the are determined to be missing a backport. label Dec 3, 2025

[Lock Manager] Handle alias resolution when checking lock index mappings #244559

[Lock Manager] Handle alias resolution when checking lock index mappings #244559

Uh oh!

Conversation

SrdjanLL commented Nov 27, 2025 • edited by kibanamachine Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Testing

Checklist

Identify risks

Reviewer notes

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sorenlouv Nov 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elasticmachine commented Nov 28, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sorenlouv Nov 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elasticmachine commented Nov 28, 2025

Uh oh!

sorenlouv left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kibanamachine commented Dec 2, 2025

Uh oh!

elasticmachine commented Dec 2, 2025

💚 Build Succeeded

Metrics [docs]

History

Uh oh!

kibanamachine commented Dec 2, 2025

💔 All backports failed

Manual backport

Questions ?

Uh oh!

kibanamachine commented Dec 3, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

SrdjanLL commented Nov 27, 2025 •

edited by kibanamachine

Loading

sorenlouv Nov 28, 2025 •

edited

Loading

sorenlouv Nov 28, 2025 •

edited

Loading