Breeze 0.102 doesn't allow to approve more than 200 patches on Linux

[Baltix]

Description

I've 333 Linux updates patches to apply on our fleet, but Breeze 0.102 allows to select and approve only 200 patches on Linux, see attached screenshot:

Because of this I can't apply all patches on devices - half patches have unapproved status :(

Steps to Reproduce

1. Go to Patch Management -> Patches tab
2. Choose Rows per page -> 200 on the bottom
3. Try to select all Patches

Expected Behavior

Breeze shoud display several pages if there are more than 200 patches
All patches should have possibility to be selected.

Actual Behavior

Only one page - 200 patches are shown and can be selected, see attached screenshot

Component

Web Dashboard

Version

0.102

Relevant Logs

Additional Context

No response

[ToddHebebrand]

Confirmed — good catch, and it's not a server-side limit, which matters for the workaround below.

Root cause: the web UI fetches exactly one page. apps/web/src/components/patches/PatchesPage.tsx issues a single GET /patches?limit=200 and never pages through the rest — 200 is MAX_PAGE_LIMIT in apps/api/src/routes/patches/helpers.ts, the API's per-page ceiling. All filtering, sorting, and "select all" then operate client-side over that already-truncated in-memory array (PatchList.tsx, usePatchSelection.ts), so with your 333 patches only the first 200 by creation date ever reach the browser, and select-all silently tops out there.

Not Linux-specific: the same code path serves every OS — it surfaces first on Linux because apt/dnf catalogs produce far more discrete patch entries per fleet than Windows does.

The approval endpoint itself has no cap. POST /patches/bulk-approve accepts an arbitrary-length patchIds array. So until the UI fix ships, you can approve all 333 in one shot against the API directly: fetch GET /patches?limit=200&page=1 and page=2 with your filters, merge the ids, and submit one bulk-approve call — the server will take it.

Fix shape: make the patches fetch page until exhausted (short-term), with server-side filter/sort/select-all as the scalable follow-up.

Status: confirmed as a bug; fix tracked here.