Public SavedObjectsClient.resolve fails for "aliasMatch" outcome #113160
Labels
bug
Fixes for quality problems that affect the customer experience
Feature:Security/Sharing Saved Objects
Platform Security - Sharing Saved Objects feature
impact:low
Addressing this issue will have a low level of impact on the quality/strength of our product.
loe:small
Small Level of Effort
Team:Security
Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Kibana version: 7.16 (unreleased)
Describe the bug:
Starting in #112025, the public SavedObjectsClient (SOC) batches individual
resolve
requests into a singlebulkResolve
.This works well for regular "exactMatch" outcomes".
However, if a saved object resolves with an "aliasMatch" outcome, then the SOC treats the object as not found and runs into an error.
Steps to reproduce:
http://localhost:5601/s/test2/app/lens#/edit/725a2be0-1ace-11ec-acee-9f628a4e2e5b-test2
Expected behavior:
You should be redirected to the page for the new object ID,
http://localhost:5601/s/test2/app/lens#/edit/725a2be0-1ace-11ec-acee-9f628a4e2e5b-test2-newId
Any additional context:
I also observed another regression
that appears to have been introduced with #108637, where loading a saved object that has a reference to an index pattern that resolves in a "conflict" outcome results in an endless loop of API calls to_bulk_resolve
. This can be demonstrated with the staging data above by navigating tohttp://localhost:5601/test3/app/lens#/edit/725a2be0-1ace-11ec-acee-9f628a4e2e5b-test3
. I can verify this regression by reverting 119c742 and that page starts working as expected. Just mentioning this because I plan to fix both problems in the same PR.Edit: the second problem turned out to be an issue with how the Lens top nav tries to load index patterns, if it doesn't find one (either because the data plugin threw an error for the "conflict" outcome, or the index pattern wasn't found), it will trigger an infinite loop attempting to load the index pattern.
Edit 2: the second problem now has its own issue (#113377) and will be fixed separately.
The text was updated successfully, but these errors were encountered: