ListEvents can exceed page size after label filtering

Abierto
  • ¿Algo no está bien?
#7,085 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

  • #7086 de @rootp1 — cerrado sin fusionar

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
62/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
go
Área
api, backend

Línea de trabajo

Comienza en pkg/app/server/grpcapi/web_api.go, en WebAPI.ListEvents y su bucle de paginación filtrado por etiquetas, y compara después la ruta equivalente de ListDeployments. Añade o actualiza pruebas para resultados de etiquetas densos, dispersos y sin coincidencias, y verifica que las respuestas respeten PageSize mientras que la continuación mediante cursor no tenga eventos duplicados ni omitidos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Go
Estrellas
1.4k
Forks
391
Merge medio
4 d 1 h
PR fusionados (30 d)
58

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pipe-cd/pipecd

Todos los issues de pipe-cd/pipecd

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.