feat(machine-id): Bot instances list (web)

[nicholasmarais1158]

Description

This change adds a new page to the Machine & Workload Identity section for Bot Instances. The page shows a paginated list of all "active" (i.e. with non-expired credentials) bot instances. Paging and search term filter are powered by the backend. Sorting is not supported - the list is naturally sorted by bot name and then instance id.

The page and search state are stored in the URL.

Tested locally with 100,000 instance records. Page load and initial data page are fast. Using a search term that returns fewer rows than the page size (20) takes 1.5 seconds, as the full data set needs to be processed on the backend.

Updates #53584

Changelog: View and explore all "active" bot instances

Changes

• Add Map slices utility
• Add endpoint to list bot instances with paging and search filter (GET /webapi/sites/:site/machine-id/bot-instance)
• Add [Machine & Workload Identity > Bot instances] nav item
• Add page to list bot instances (tabularly) with backend paging and filter - sort is not supported
• Add page info panel for bot instances
• Fix a minor UI glitch on bots welcome/tutorial component

Demo (network throttled)

Screen.Recording.2025-05-22.at.12.49.40.mov

[zmb3]

Paging, sorting and filter are all done client-side

Why?

[nicholasmarais1158]

Paging, sorting and filter are all done client-side

Why?

It's a compromise made to get an initial implementation out. We have a mixture of approaches throughout the app today; some fully client-side (Users page), some have backend support (Resources page), and others use the backend but have reduced scope like not supporting sorting (Roles page). The goal is to deliver as full an experience as possible, without tackling challenges at a 'platform' (system-wide, shared capabilities) level.

Supporting sorting, and pagination of sorted results, requires indexes for large datasets (such as bot instances). Each field required for sorting will need to be indexed to keep the operation performant. Data like version numbers can't be sorted as a string without first parsing them (using semver, for example), which adds complexity to indexes over this type of data.

While focusing on adding incremental value is advised, it should not compromise the quality and trust of the product. 100k bot instance records is currently the maximum any exiting client might have. At this level, a page load takes 7+ seconds, every sort operation 4+ seconds, and a filter around 700ms. These timings reduce user experience - sorting particularly, as it has no indication of progress. In my opinion, the experience is borderline 'acceptable' as it stands.

An alternative initial approach that can be considered, is to descope sorting, move filtering (keyword match) to the backend, and use the existing backend paging capability. This addresses the poor user experience, but at the cost of reduced functionality. Then, as a separate iteration, an approach leveraging the work being done on the in-memory cache should allow sorting to be added with relatively low effort.

Suggestions, challenges and other points of view are welcome. 🙏

[zmb3]

We have a mixture of approaches throughout the app today; some fully client-side (Users page), some have backend support (Resources page), and others

For some context, basically everything started out fully client-side, and we spent a couple years slowly replacing non-paginated APIs with paginated ones to fix a bunch of issues that customers ran into at scale.

At this point, the users page is one of the last remnants of the old non-paginated APIs, and @rudream has a goal this quarter to swap it out for the paginated API.

Unless there is very strong reason not to, I'd prefer that all new endpoints use server-side pagination from the start. Otherwise, we're just deferring the inevitable.

[ryanclark]

Sorry for the delay!

[backport-bot-workflows]

@nicholasmarais1158 See the table below for backport results.

Branch	Result
branch/v17	Failed