Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Duration handling and plan fidelity follow-ups from #110

Abierto
  • ¿Algo no está bien?
#111 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
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
docker, go
Área
devops, infrastructure

Línea de trabajo

Comienza con los puntos de entrada indicados en internal/app/backup_schema.go, runtime.go, constraints.go, generate.go, internal/engine/plan.go y roll.go; después inspecciona las pruebas relacionadas de duration, plan y drain-budget. Aborda los seis seguimientos independientes sin cambiar la asimetría indicada de la ejecución rolling. Se considera terminado cuando la validación, las descripciones generadas, la salida del plan, el manejo más seguro de grace malformado y el comportamiento de clamp sean coherentes y estén cubiertos donde se mencionan pruebas.

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

Descripción

bug documentation

Review findings from #110 that were deliberately deferred rather than patched in at merge time. None blocked that fix; all are small and independent.

1. PositiveDuration still wraps on large day counts, and now disagrees with ParseDuration

internal/app/backup_schema.go:211-224 multiplies its day branch unchecked, so max_data_loss: 213504d wraps to 25m26s, passes the days <= 0 guard (which checks the day count, not the product), and then passes validateBackupPolicy's one-minute floor. Same for retention.window.

#110 capped app.ParseDuration at maxDurationDays, so the two parsers now diverge on the same field: backup_walg.go:331/:520 compute archive timeout and retain count from the wrapped 25m26s, while backup_state.go:339 and backup_postgres_ops.go:442 get false and silently fall back. Before #110 both wrapped identically — worse, but at least consistent.

Fix: apply the same maxDurationDays cap inside PositiveDuration's day branch. ParsePostgresDuration's d arm (runtime.go:456) has the same unchecked multiply, though its input is a server-reported setting rather than authored.

2. Bounded fields have a self-contradicting description

Every field #110 capped now reads "…at most 7d. … Expects a duration such as 30s, 5m, 1h30m or 14d." The suffix comes from gDur's blurb (internal/app/constraints.go:38-39) and names an example the same sentence forbids. Eight entries across both schema copies and the two generated .mdx tables.

Fix: drop 14d from the appended example for ceiling-bearing fields only — it remains legitimate for retention windows, so gDur should not change globally.

3. The rolling plan hides its drain step

#110 aligned the recreate branch of Describe with what recreateRoleForRelease does. The rolling branch (internal/engine/plan.go:504-511) still never mentions the authored drain.wait sleep or the non-TERM docker kill --signal that retireContainer performs (roll.go:200-208). With strategy: rolling and drain: {signal: USR1, wait: 12s}, the plan hides a kill and a pause the deploy takes.

Note the execution asymmetry is deliberate and should stay: rolling suppresses the signal when it is TERM, because an early TERM would kill a container still serving traffic.

4. interval has a ceiling but no floor, and zero means something different than intended

checkLifecycleDuration rejects durations above 7d but accepts interval: 500ms, which docker create then rejects with "cannot be less than 1s" — a failure that could be caught at validation.

Separately, composeDuration's "an explicit zero is a real instruction" rationale holds for start_period (Docker's default is 0, so 0 genuinely means no grace) but not for interval, where Docker reads 0 as unset and probes at 30s while HealthInterval() models 5s. Not dangerous — the drain budget reads the baked value, and bakedHealthcheck maps 0 to 30s correctly — but the model and the runtime disagree, which is the class of thing #110 set out to remove.

5. The bakedHealthcheck clamp is silent and untested

internal/engine/roll.go:252-256 clamps out-of-range values read back from a container without logging. The operator sees only "container never reported unhealthy… proceeding after buffer", which points at the container rather than at the out-of-range baked timing that caused it. It is also the one behavioural change in #110's engine half with no test.

Fix: a warnf at clamp time, and a case in drain_budget_test.go with a baked Interval above the ceiling.

6. applyStopGrace would fail dangerously if its guard were ever bypassed

internal/app/generate.go:977 calls composeDuration(w.Drain.Grace, 0). Validation guarantees a non-empty grace parses, so the fallback is currently unreachable — but if that ever changed, a malformed value would render as stop_grace_period: 0s, which is an immediate SIGKILL: the most dangerous possible reading of a typo. Dropping the key, or failing loudly, would fail safer than defaulting to zero grace.

Lenguaje dominante
Go
Estrellas
3
Forks
0
Merge medio
2 h 46 min
PR fusionados (30 d)
38

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 labstack/onebox

Todos los issues de labstack/onebox

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.