`GET /api/v1/sdk/ruleset` stops answering under sustained overload and does not recover after a pause

Abierto
  • ¿Algo no está bien?
#1,728 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
api, backend, performance

Línea de trabajo

Start by locating the handler for GET /api/v1/sdk/ruleset and the in-process tests for that route. Read how the handler manages requests under load, then add a test that drives it past capacity and fails on release 0.42.0. Done when the test shows the route continues answering some requests during overload and recovers after load pauses.

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

Descripción

bug

What happens

Under sustained overload, GET /api/v1/sdk/ruleset stops answering altogether, and it is still not answering after the load
has paused for 12 to 17 seconds.

Seen in all three runs of the ruleset scenario in scale measurement run 41732112985 (release 0.42.0, GitHub-hosted runners,
two different CPU models). In each run, at the first step the API could not keep up with:

  • answered requests fell to zero for the rest of the step (after 6 to 30 seconds of normal answers);
  • the API's CPU use fell (from about 65-71% to 13-40% of a core) instead of staying saturated, and the database had no
    active connections serving it;
  • the proxy recorded every request in that stretch as closed by the client (499);
  • the next step started after a 12-17 s pause and answered nothing from its first second (0 of 2,268, 0 of 2,856 and 0 of
    3,598 requests).

What should happen

Past its capacity, the route may slow down or refuse some requests, but answered throughput should not collapse to zero, and
the route should answer normally again soon after the load drops.

Why it matters

Server-side SDKs in local-evaluation mode poll this route to refresh their rules. During a stall they keep serving their
last-known rules, as designed, but cannot pick up a change, so a flag change or a kill switch does not reach them until the
route recovers.

Notes

  • Priority: medium, before launch (D213: it touches use case #4, server-side local evaluation).
  • The measurement's report labelled these steps as database-bound ("serialised"). That label is wrong for this case and is
    being corrected in the scale harness as part of #1608. The run itself is discarded from the published evidence.
  • A fix needs an in-process test that drives this route past its capacity and fails on 0.42.0's code.
Lenguaje dominante
Python
Estrellas
0
Forks
4
Merge medio
5 h 19 min
PR fusionados (30 d)
503

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 Controlvar/controlvar

Todos los issues de Controlvar/controlvar

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.