ListEvents can exceed page size after label filtering

Đang mở
  • Có gì không ổn?
#7,085 3 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

Chưa có ai nhận issue này.

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

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
62/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.ListEvents và vòng lặp phân trang được lọc theo nhãn của nó, sau đó so sánh với đường dẫn ListDeployments tương đương. Thêm hoặc cập nhật các bài kiểm thử cho kết quả nhãn dày, thưa và không có kết quả khớp, đồng thời xác minh rằng các phản hồi tuân thủ PageSize trong khi việc tiếp tục bằng cursor không có event bị trùng hoặc bị bỏ sót.

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

Mô tả

What happened:

WebAPI.ListEvents applies label filtering after fetching datastore pages, then keeps appending matching events while scanning additional pages until it has at least PageSize matches. If the final scanned page contains multiple matching events after the threshold is crossed, the response can exceed the requested logical page size. The handler then returns the datastore cursor from the final scanned page, which makes filtered pagination unstable for event timelines.

Summary

ListEvents can return an oversized filtered response when label matches are spread across multiple datastore pages.

Affected Area

pkg/app/server/grpcapi/web_api.go, specifically WebAPI.ListEvents and its label-filtered pagination path.

What you expected to happen:

ListEvents should return one logical filtered page, no larger than the requested PageSize, and provide a cursor suitable for continuing to the next filtered page without duplicates or dropped events.

Expected Behaviour

The API should enforce a stable logical page size after label filtering and return a cursor for the next filtered page.

How to reproduce it:

  1. Seed or mock multiple datastore pages of events with label matches spread across pages.
  2. Call WebAPI.ListEvents with Options.Labels and a PageSize smaller than the total matching events.
  3. Make the first page contain fewer matching events than PageSize, and a later fetched page contain enough matches to cross the threshold by more than one event.
  4. Observe that the response includes more than PageSize events because every matching event from the final scanned page is appended.

Actual Behaviour

The endpoint can return an uncapped list of matched events encountered during the scan, exceeding the requested page size.

Technical Evidence

ListEvents builds datastore ListOptions with Limit: pageSize, fetches one page, filters by labels in memory, then repeats while len(filtered) < pageSize. Inside the repeat loop, every matching event from the newly fetched datastore page is appended. There is currently a TODO noting the overflow risk immediately before returning the response:

  • pkg/app/server/grpcapi/web_api.go: // TODO: Think about possibility that the response of ListEvents exceeds the page size

This mirrors the same post-filter pagination risk that exists in ListDeployments.

Suspected Root Cause

Label filtering happens after datastore pagination, but the filtered slice is never capped back to the requested logical page size before the response is returned. The returned cursor is the datastore cursor from the final scanned page.

Proposed Direction

Refactor the filtered pagination path so ListEvents only returns up to PageSize filtered events. If possible, share the helper with the equivalent ListDeployments path so both handlers use consistent cursor semantics.

Acceptance Criteria

  • ListEvents enforces a stable logical page size after label filtering.
  • Cursor-based continuation yields no duplicate or dropped events.
  • Tests cover dense matches, sparse matches, and zero-match scenarios.

Environment:

  • piped version: Not applicable; this is a control-plane WebAPI handler issue.
  • control-plane version: Current upstream master as of 2026-07-24.
  • Others: Not applicable.
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.