Provide one paginated connection for workloads without usable vulnerability data
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
- #552 de @ybelMekk — cerrado sin fusionar
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
Línea de trabajo
Start by reading the team-workloads connection and its existing sbomStatus filter, then trace how v13s listings are sorted and paginated. The issue does not name files or tests, so locate the relevant connection tests and run them before making changes. Done means one snapshot produces an accurate, duplicate-free count and deterministic pagination for both statuses, with the specified processing-summary cases covered; pull request #552 is already open.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
nais/console-frontend#650 currently combines NO_SBOM and PROCESSING by issuing two team.workloads requests. TeamWorkloadsFilter.sbomStatus accepts only one status, and the two calls to v13s are independent snapshots. A NO_SBOM -> PROCESSING transition can appear twice, inflate totalCount, and break keyed rendering. Some PROCESSING workloads already have usable current/previous-tag vulnerability summaries and belong in the priority groups instead.
Expose an additive, server-filtered team-workloads connection for workloads not represented by a usable vulnerability summary, including relevant NO_SBOM and PROCESSING rows. Filter from a single v13s listing/snapshot before sorting and slicing, return accurate totalCount, and retain the existing NAME/ENVIRONMENT ordering and tie-breaks. Keep the existing sbomStatus filter for current consumers.
Acceptance: tests for a status transition, processing with/without a usable summary, no duplicate IDs/counts, and deterministic pagination across both statuses. Once available, console-frontend can replace the two status queries and merge paginator. Related: nais/v13s#478 and nais/api#550.
- Lenguaje dominante
- Go
- Estrellas
- 3
- Forks
- 2
- Merge medio
- 19 h 14 min
- PR fusionados (30 d)
- 31
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de nais/api
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
Valkey filterAbierto
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
Issues similares
-
copilot-api domain:platform go
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
docs: clarify gh api -f vs -F and @-file expansion in the gh skillPosiblemente ocupada @MatiasOlivera la tomó hoy. Abiertoenhancement
Dificultad 2/5 Medio día Aptitud para principiantes 62/100
cli/cli#14701 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
aws/aws-advanced-go-wrapper#612 ·
-
Say in the changelog that the text-index update cannot be rolled backPosiblemente ocupada @praetorianer777 la tomó hoy. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
praetorianer777/GoTome#275 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
SAP/crossplane-provider-btp#1118 ·
Los mantenedores suelen responder en 1 día