Filter the v2 list alerts endpoint by tag, name, source and state

Abierto Apto para principiantes
  • ¿Algo no está bien?
#3,468 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@andrewdunndev ya está trabajando en esto.

Desde el 30/10/2026.

  • #3506 de @andrewdunndev — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
78/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
api, backend

Línea de trabajo

Comienza en packages/api/src/routers/external-api/v2/alerts.ts extendiendo paginationQuerySchema con tag, search, source, state opcionales. Luego actualiza getAlertsWithDisplayRefs en packages/api/src/controllers/alerts.ts para pasar esos filtros a Alert.find, reflejando la lógica en packages/api/src/controllers/alertsPage.ts. Ejecuta las pruebas de integración para el endpoint v2 alerts para confirmar cada filtro, su combinación AND y el recuento total filtrado.

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

Descripción

external

What are you trying to do?

I manage alerts from an automation that keeps them declarative: it owns a set of alerts, tags each one with a key, and on every run looks up its own alerts to decide what to create, update or delete. It uses the v2 API with an API key.

Today GET /api/v2/alerts takes only limit and offset (packages/api/src/routers/external-api/v2/alerts.ts, paginationQuerySchema), and getAlertsWithDisplayRefs runs Alert.find({ team }) with no other condition (packages/api/src/controllers/alerts.ts). So the client has to page through every alert on the team and match tags client-side, including alerts that people created by hand and that it should never touch.

Alerts already carry displayName and tags (#3063), and the internal list endpoint, GET /api/alerts, already filters by tag, display name search, source and state (#3134, packages/api/src/controllers/alertsPage.ts). The v2 list endpoint is the one place those filters are not exposed.

What would you like to see?

Optional query parameters on GET /api/v2/alerts:

  • tag: repeated, matches alerts with any of the given tags, the way the internal list endpoint accepts them (?tag=a&tag=b)
  • search: case-insensitive substring match on displayName
  • source: repeated, any of saved_search, tile, inline
  • state: repeated, any of the alert states

Filters combine with AND. meta.total and X-Total-Count count the filtered set, so a client can page within its own alerts. Sort order and limit/offset paging stay as they are.

All parameters are optional, so a request with none of them returns exactly what it does today.

Alternatives you've considered

Listing everything and filtering client-side, which works for a small team but grows with the team's alert count and makes the client read alerts it has no business with.

Encoding the key in displayName and matching on that client-side, which has the same cost and conflicts with people renaming alerts in the UI.

Anything else?

I have a branch with integration tests covering each filter, the AND combination, the filtered total, and the no-filter case, and will open the PR once this is marked Accepting PR. Happy to adjust the parameter names or drop source and state if tag and search are enough.

Lenguaje dominante
TypeScript
Estrellas
10k
Forks
501
Merge medio
2 d 4 h
PR fusionados (30 d)
144

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 hyperdxio/hyperdx

Todos los issues de hyperdxio/hyperdx

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.