ci(release-truth): que el chequeo rápido pueda fallar rápido - #249
Merged
Conversation
`release-truth` corre `generate_release_truth.py --check` en unos 30 segundos, pero tenia `needs: test`. La MISMA staleness la detecta `tests/test_release_truth.py` dentro de la suite, asi que `test` fallaba primero y este job quedaba `skipped` — justo en la unica situacion donde servia. Medido hoy sobre el PR #248: 6 jobs de test en rojo, el de Windows 3.12 tras 1h10m, para reportar exactamente lo que este job reportaba en medio minuto. Verificado en la corrida 33405024683: contract-witness success 14:51, release-truth SKIPPED 16:01. Es la cuarta vez en un dia que caigo en la misma trampa: el generador cuenta funciones de test, agregar una sin regenerar deja el archivo viejo. La leccion no es "acordarse" — es que el chequeo que ya existia no podia dispararse. Sin `needs`, el job es independiente: hace checkout, instala y corre --check. No consume nada que produzca `test`.
wolverin0
added a commit
that referenced
this pull request
Aug 31, 2026
…de verdad (#250) * fix(tests): la espera de arranque del servidor MCP tiene que esperar de verdad `test_authenticated_mcp_http_delivers_disposable_capture` cayo CUATRO veces el 2026-08-31, siempre en Windows, con `authority_unavailable`. Entre 1 y 1,5 horas de suite cada vez, mas el relanzamiento que vuelve a pagarla entera. NO era aleatorio. El bucle de arranque del fixture tenia dos defectos: for _ in range(100): try: if httpx.get(health, timeout=0.2).status_code == 200: break except httpx.HTTPError: time.sleep(0.02) # <- el sleep SOLO aca 1. Sin sleep en la rama de "respondio pero no 200" —el caso normal mientras arranca— el bucle giraba sus 100 vueltas en milisegundos y se rendia sin haber esperado nada. 2. El limite estaba en VUELTAS, no en tiempo: el presupuesto real dependia de si cada intento fallaba rapido o agotaba su timeout. O sea que no habia presupuesto. Por que el sintoma mentia: el fallo no aparecia como un error de arranque legible. El test avanzaba, la llamada MCP fallaba, y `_classify_transport_error` (backend.py:273) la reportaba como `authority_unavailable`, que es su FALLBACK para cualquier error de transporte sin clasificar. `_wait_until_healthy` reemplaza el bucle: limite por TIEMPO, sleep en todos los caminos, timeout por intento de 1s en vez de 0,2s. NO es un reintento y hay un test que lo fija: un servidor que nunca levanta sigue fallando. No repite aserciones ni tolera un fallo persistente — que era el riesgo de la alternativa que descarte (marker de reintento, ademas de exigir una dependencia nueva; ninguna de pytest-rerunfailures/flaky/pytest-retry esta instalada). La otra alternativa, un job aparte no bloqueante, tapa la caida por completo, que contradice el criterio del PR #249: el chequeo tiene que llegar a hablar. Barra roja verificada contra el bucle ORIGINAL: caen exactamente los dos tests que anclan los defectos y los otros tres pasan, porque ese comportamiento ya estaba bien. 13/13 en la suite real de hermes, 5/5 en los nuevos, ruff limpio, release-truth regenerado ANTES de commitear. * docs(handoff): estado al cierre del 2026-08-31 Los 8 PRs del dia, los resultados MEDIDOS (perfil destrabado tras 10 dias, PPR-7 volviendo a emitir, corpus 18% -> 96% agrupado, cero claims vivas en tenant NULL), los 9 items que quedan abiertos con su evidencia, y las seis trampas que costaron tiempo hoy — incluida la de release-truth, en la que cai cuatro veces.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
El defecto
release-truthcorregenerate_release_truth.py --checken ~30 segundos. Pero la misma staleness la detectatests/test_release_truth.pydentro de la suite. Así quetestfalla primero y este job quedaskipped— precisamente en la única situación donde servía.El chequeo rápido estaba downstream del lento que lo duplica. Nunca podía llegar primero.
Medido hoy, PR #248, corrida
33405024683contract-witnesstest×6release-truthSeis jobs en rojo y setenta minutos para reportar lo que este job reportaba en medio minuto.
Por qué ahora
Es la cuarta vez en un día que caigo en la misma trampa: el generador cuenta funciones de test, y agregar una sin regenerar deja el archivo viejo. La lección no es "acordarse mejor" — es que el chequeo que ya existía no podía dispararse.
Seguridad del cambio
Sin
needs, el job es independiente: checkout,pip install -e,--check. No consume nada que produzcatest. El costo es un runner más en paralelo; el beneficio es que la señal llega en 30 segundos en vez de nunca.