ListDeployments returns unbounded filtered pages with an unstable cursor

Đang mở
#7,074 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

@AnKiT-GaRG2 đang làm issue này rồi.

Từ ngày 22/10/2026.

  • #7075 của @rootp1 — đã đóng, không merge

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
70/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
go
Lĩnh vực
api, backend

Hướng nghiên cứu

Bắt đầu trong pkg/app/server/grpcapi/web_api.go tại WebAPI.ListDeployments và vòng lặp lọc theo label, sau đó chạy hoặc kiểm tra các unit test tập trung cho handler này. Thêm kiểm thử hồi quy cho các kết quả khớp dày và thưa trên nhiều trang datastore; được xem là hoàn tất khi các response đã lọc tuân theo PageSize và các request tiếp theo tiếp tục mà không có bản sao hoặc khoảng trống.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

What happened:
WebAPI.ListDeployments can return more than one logical page of deployments when label filtering is used. The handler paginates in the datastore layer, applies label filtering in memory, and keeps appending matches from subsequent datastore pages until the scan stops. That means one response can grow beyond the requested PageSize while still returning only the last datastore cursor.

Summary

ListDeployments does not enforce a stable filtered page size after applying label filters.

Affected Area

  • pkg/app/server/grpcapi/web_api.go
  • WebAPI.ListDeployments

Steps to Reproduce

  1. Arrange multiple deploymentStore.List pages where several deployments match the requested labels.
  2. Call WebAPI.ListDeployments with those label filters and a PageSize smaller than the total number of matching deployments.
  3. Observe that the response accumulates matching deployments across datastore pages into a single Deployments array.
  4. Observe that the returned cursor is only the final datastore cursor rather than a cursor aligned to the filtered response boundary.

Actual Behaviour

One response can contain more than the intended logical page size when label filtering is applied, and the cursor does not describe a stable resume point for filtered pagination.

Technical Evidence

  • The current implementation filters the first datastore page in memory and, if fewer than PageSize items remain, continues fetching more datastore pages and appending every matching deployment.
  • The handler currently returns filtered without truncating it to PageSize and includes a TODO noting that ListDeployments can exceed the page size.
  • Relevant code: pkg/app/server/grpcapi/web_api.go around the ListDeployments label-filter loop.

Suspected Root Cause

Filtering happens after datastore pagination, but the filtered result set does not have its own page boundary or resume cursor.

Proposed Direction

  • Keep fetching datastore pages until the filtered response reaches the requested logical page size.
  • Stop at the exact filtered page boundary instead of returning every matched deployment gathered during the scan.
  • Return a cursor that resumes from the correct datastore position for the next filtered page.
  • Add regression tests that cover dense and sparse label matches across multiple datastore pages.

Acceptance Criteria

  • ListDeployments never returns more than the requested logical page size when label filters are used.
  • A follow-up request using the returned cursor yields the next filtered page without duplicates or gaps.
  • Regression tests cover multi-page filtered pagination.

What you expected to happen:
ListDeployments should honor a stable filtered page size and return a cursor that resumes exactly after the last item included in the filtered response.

How to reproduce it:

  1. Arrange or mock multiple deploymentStore.List pages containing deployments with matching labels.
  2. Call WebAPI.ListDeployments with label filters and a PageSize smaller than the total filtered match count.
  3. Inspect the response and verify that it currently returns more than one logical page of matches.

Environment:

  • piped version: Not applicable
  • control-plane version: master as of July 22, 2026
  • Others: Reproducible from the current pkg/app/server/grpcapi/web_api.go implementation and a focused unit test.
Ngôn ngữ chính
Go
Star
1.4k
Fork
391
Merge trung bình
4 ngày 1 giờ
Pull request đã merge (30 ngày)
58

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pipe-cd/pipecd

Tất cả issue của pipe-cd/pipecd

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.