probation_start is set while the criterion is still failing
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 53/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Área
- backend-api-design
Línea de trabajo
Start with state_machine._probation_start and the outlived_grace branch in transition(), which the issue identifies as stamping probation_start; trace how confirmed status changes from fail to pass. Check the existing backfill approach for rows stamped mid-failure. Done means probation starts only on recovery, the read-side compensations can be removed, and existing affected rows are corrected.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
probation_start is stamped as soon as a failure is confirmed, then re-stamped to "tomorrow" on every failing night after that. So a set probation_start does not mean the criterion is serving probation — it may still be failing.
Every reader has to compensate with the same extra check:
| Reader | Compensation |
|---|---|
is_serving_probation (API) |
confirmed_status == 'pass' |
feed_search.sql |
confirmed_status = 'pass' |
roll_up_on_probation |
cancels on any confirmed failure |
state_machine.phase() |
returns ON_PROBATION for both, leaves it to the caller |
Recent fixes have all been on the read side: #1840, #1841, #1842, #1843.
Fix
Stamp probation_start only on the recovery — the run where confirmed_status goes fail → pass. last_confirmed_failure_at already records that a failure happened, so the "stamp tomorrow on every failing night" trick is no longer needed to land the start on the repair day.
Then probation_start is not None means serving probation, and the four compensations above come out.
state_machine._probation_start, plus theoutlived_gracebranch intransition(), which stamps too- backfill for rows currently stamped mid-failure
- Lenguaje dominante
- Python
- Estrellas
- 34
- Forks
- 7
- Merge medio
- 12 h 7 min
- PR fusionados (30 d)
- 7
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una 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 MobilityData/mobility-feed-api
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
MobilityData/mobility-feed-api#1846 ·
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
MobilityData/mobility-feed-api#1755 · 1 reacción ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
MobilityData/mobility-feed-api#1647 ·
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Todos los issues de MobilityData/mobility-feed-api
Issues similares
-
[Bug]: Revit selector reads process ids 2000-2099 as years (flaky AgentClientTests.AYearOrAProcessIdSelectsTheHost)Posiblemente ocupada @Wurschdhaud la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
pyrevitlabs/pyRevit#3817 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
521xueweihan/HelloGitHub#4074 ·
-
follow-up
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
Helm chart: allow setting ingressClassName on the IngressPosiblemente ocupada @commarla la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
pgadmin-org/pgadmin4#10658 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100