feat: paginate instance management

[tju-yxq]

Summary

• add backward-compatible GET /api/instances/page with the existing type/search filters and bounded pagination
• return items, total, page, and size; default to page=1, pageSize=20, and cap page size at 100
• reject invalid page/pageSize before repository or provider access
• add a repository count query for the current type/search filter
• preserve the existing unpaginated endpoint for selectors and keep resource-count and display-name behavior unchanged
• update instance management to use server-driven pagination, a server total, 20/50/100 page sizes, and page reset on filter changes
• keep request sequencing and stale-response protection

Why

The management page previously loaded and rendered every configured instance in one request. Other Studio inventories already use server-side pagination, so this brings the primary instance inventory to the same bounded contract as cloud credentials, data sources, Studio users, and query history.

Tests

• focused backend: InstanceServiceTest,InstanceControllerTest — 84 tests passed
• backend full suite: 1,560 tests passed; Checkstyle 0 violations
• focused frontend: instance API/service/page tests — 3 files / 32 tests passed
• npm run lint -- --quiet: 0 errors (3 pre-existing warnings)
• npm run build: passed
• git diff --check: passed

Production changes: 122 additions / 9 deletions, naturally exceeding 100 production lines without test padding.

Closes #2542

[RockteMQ-AI]

Review of PR #2543

This PR modifies 10 files with +320 -79 lines.

Findings

• [Info] Chained method calls detected — consider null-safety checks

Suggestions

Please review the findings above and address any critical or warning items.

---

Automated review by github-manager-bot

[RockteMQ-AI]

Summary

This PR adds server-side pagination for instance management (backend /page endpoint + frontend pagination controls with search/filter). The overall structure is clean — good input validation, proper race-condition handling in the frontend with requestIdRef, and solid test coverage.

One performance concern: the paginated service method still loads all instances into memory before slicing. See inline comment for details.

---

Automated review by github-manager-bot

[RockteMQ-AI]

[Performance] This method calls listInstances(type, normalizedSearch) which loads ALL instances into memory (including remote resource-count fan-out for every instance) and then paginates in-memory with subList. This defeats the purpose of pagination — for a deployment with hundreds of instances, every page request still triggers N remote API calls.

Consider paginating at the database level instead:

1. Use instanceRepository with LIMIT/OFFSET (or MyBatis-Plus Page) to fetch only the current page of instances
2. Then do the resource-count fan-out only for those instances on the current page

This would reduce both DB load and remote API calls from O(N) to O(pageSize) per request.

[RockteMQ-AI]

[Info] The existing GET / endpoint (line 43) still returns the full unpaginated list. Consider whether both endpoints are needed long-term, or if the old one should be deprecated once the frontend fully migrates to /page. Having two endpoints with overlapping behavior can lead to maintenance burden.

[tju-yxq]

Thanks for catching this. I moved pagination into the database layer so the service no longer loads all instances and no longer fans out resource-count requests for instances outside the current page.

• Added \InstanceRepository.findPage(...), implemented with MyBatis-Plus \selectPage\ and the same type/search filters.
• \InstanceService.listInstances(...)\ now uses that repository page and fills resource counts/region names only for the returned \pageSize\ rows.
• The paginated path no longer calls \indAll, \indByTypeAndSearch, or in-memory \subList; database reads and remote count fan-out are now O(pageSize), not O(total inventory).
• Added tests proving the repository applies filters/pagination at SQL level and proving the service never falls back to the full-list repository methods.

Focused verification: \InstanceServiceTest, \InstanceControllerTest, and \MybatisPlusInstanceRepositoryTest\ — 102 tests passed, Checkstyle clean, \git diff --check\ clean. Pushed as commit \3255cf35\ (\ix: page instances in the database).

I kept the legacy unpaginated endpoint for now because existing instance selectors still consume it. We can deprecate or migrate those callers separately once the paginated management endpoint is stable.

[RockteMQ-AI]

Summary

Previous concerns have been addressed. The paginated endpoint now uses database-level pagination via instanceRepository.findPage() (MyBatis-Plus Page), which correctly avoids loading all instances into memory. The existing unpaginated endpoint is preserved for backward compatibility — this is fine as a migration path.

LGTM — ready to merge.

---

Automated review by github-manager-bot

[lizhimins]

Thanks for the contribution. After review we are not taking instance-list pagination in this project: per an explicit product convention, each user has a limited number of instances (tens at most), so the instance list intentionally returns the full set without server-side or client-side pagination (pagination={false}). This PR also bypasses the established backend ordering contract (APACHE instances by name, then cloud vendors by region → instance id, unified in InstanceService.listInstances) via orderByAsc("id"), and adds unused countAll()/count() repository methods. Closing accordingly.