Skip to content

Fix findLabelSelector and matchingLabelSelector#16707

Merged
richard-cox merged 3 commits intorancher:masterfrom
richard-cox:fix-findLabelSelector
Feb 24, 2026
Merged

Fix findLabelSelector and matchingLabelSelector#16707
richard-cox merged 3 commits intorancher:masterfrom
richard-cox:fix-findLabelSelector

Conversation

@richard-cox
Copy link
Copy Markdown
Member

@richard-cox richard-cox commented Feb 19, 2026

Summary

Fixes #15529
Fixes #16732

Occurred changes and/or fixed issues

  • findLabelSelector
    • Ensure we correctly set the record of what's in the cache... with what's actually in the cache
    • This became out of sync
      • we were clearing the cache and setting the collection to one relevant to a labelSelector
      • we were then adding labelSelector to a record saying we had this
      • the record was ADDED to after every call instead of being reset
    • fixes vai off world
      • we fetch pods for service 1 --> change to service 2 --> we fetch pods for service 2 (cache clears pods for service 1 BUT not the record of them) --> change to service 1 --> cache has record of service 1 pods so returns all in cache, however pods are for service 2
      • we now ensure the cache list and record match matching pods
      • this doesn't affect via on world because we handle labelSelector filters like normal filters in a findPage request
  • matchingLabelSelector
    • this getter is only used in services and workload views to get pods associated with them
    • we look at the cache and get applicable resources given the labelSelector
    • the cache can have just the results of the labelSelector, or more and we should then apply the labelSelector to it
    • the fix here is to ensure that we're applying the label selector to the findPage scenario
    • fixes vai on world
      • we fetch pods for service 1 --> change to service 2 --> show cache containing pods from service 1 --> fetch pods for service 2 --> cache updates and we show the correct ones
      • to avoid this ensure we always run the selector on the pods in the cache
      • this does not affect vai off world because the cache only contains the results of the labelSelector
  • empty services list in deployment detail page

Technical notes summary

Also fixed an issue where the selector was ignored when fetching matching pods

Areas or cases that should be tested

With vai off and on

  • Core bug
    • Find two services with different amounts of associated Pods
    • Flick multiple times between the detail page of each service and ensure the Pods list contains the correct values
    • Also refresh on a service detail page and ensure Pods list contains correct values

Areas which could experience regressions

With vai off and on

  • matchingLabelSelector
    • Find two deployments with different amount of pods
    • Flick multiple times between the detail page of each deployment and ensure the Pods list contains the correct values
    • Also refresh on a detail page and ensure Pods list contains correct values
  • Longhorn - (after install)
    • --> on cluster explorer Longhorn Overview page should show card with link to longhorn service --> click --> should load long horn ui (page just needs to load, it can show errors)
    • cluster explorer --> Deployment --> longhorn-ui Detail page --> services list should be populated
  • Compliance (replacement app for CIS Benchmark)

Checklist

  • The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
  • The PR has a Milestone
  • The PR template has been filled out
  • The PR has been self reviewed
  • The PR has a reviewer assigned
  • The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
  • The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes
  • The PR has been reviewed in terms of Accessibility
  • The PR has considered, and if applicable tested with, the three Global Roles Admin, Standard User and User Base

- findLabelSelector
  - Ensure we correctly set the state of the cache given the values in the collection
  - e.g. if we've cleared the cache for a specific selector mark other selectors as missing
- matchingLabelSelector
  - if we've fetched a page assume it's a trimmed down result set ready for further trimming by selector
@richard-cox richard-cox force-pushed the fix-findLabelSelector branch from ac9d706 to 34933d2 Compare February 23, 2026 09:37
}

cache.haveSelector[selector] = true;
cache.haveSelector = { [selector]: true };
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

at some point we should remove the map part and just use cache.haveSelector=selector i chickened out though given this is bug complete week.

i can create a tech debt issue if requested

// Filter first by namespace if one is provided, since this is efficient
if (namespace && typeof namespace === 'string') {
matching = type === POD ? getters['podsByNamespace'](namespace) : matching.filter((obj) => obj.namespace === namespace);
matching = type === POD && !selector ? getters['podsByNamespace'](namespace) : matching.filter((obj) => obj.namespace === namespace);
Copy link
Copy Markdown
Member Author

@richard-cox richard-cox Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a secondary fix. matchingLabelSelector calls matching. if there's a selector we shouldn't return all pods in a namespace but go on to apply it

@richard-cox richard-cox marked this pull request as ready for review February 23, 2026 10:54
hash.pods = this.value.fetchPods();
}

if (this.serviceSchema) {
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was the fix for #16732

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes caching inconsistencies when fetching resources by label selector (notably pods for Services/Workloads) across both VAI pagination-enabled and disabled modes, and restores missing service fetching on workload detail pages.

Changes:

  • Reset selector-cache bookkeeping in loadSelector to avoid accumulating stale selectors.
  • Ensure matchingLabelSelector applies the label selector when the store currently represents a paginated result set.
  • Re-add fetching of Services in the workload detail view to populate related-services UI.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File Description
shell/plugins/dashboard-store/mutations.js Adjust selector-cache tracking to avoid stale selector records.
shell/plugins/dashboard-store/getters.js Apply label selector filtering when cache contains a page/all rather than a selector-only result set.
shell/plugins/dashboard-store/actions.js Fix typo in comment in findLabelSelector option handling.
shell/detail/workload/index.vue Fetch namespaced Services during workload detail load to repopulate related services list.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link
Copy Markdown
Member

@codyrancher codyrancher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@richard-cox richard-cox merged commit cfe38a3 into rancher:master Feb 24, 2026
42 checks passed
@richard-cox richard-cox deleted the fix-findLabelSelector branch February 24, 2026 10:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Deployment Detail Page: Services list is always empty UI shows incorrect cached elements for Pods list in Service details view

3 participants