From 70a76aedcba341d32d75a286328c1d131b6b2029 Mon Sep 17 00:00:00 2001 From: Sergio Date: Mon, 14 Sep 2026 20:13:08 +0000 Subject: [PATCH] =?UTF-8?q?=E2=9A=A0=20la=20comprobaci=C3=B3n=20que=20falt?= =?UTF-8?q?aba:=20DOS=20commits=20se=20hab=C3=ADan=20quedado=20en=20el=20g?= =?UTF-8?q?itea=20viejo?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Comparados los 845 refs de los dos lados, repo por repo. Dos diferencias: una esperada (`sergio/takana` main, el nuevo por delante con los commits del cutover — fast-forward verificado) y una que NO: `tawasuyu/tawasuyu` tenía en el viejo `b69008eb` (freebsd) y `02a9535f` (shuma, **19:48**), quince minutos DESPUÉS del snapshot final. Por qué: el gitea viejo había resucitado por OpenRC y un cliente con el DNS cacheado (el CNAME anterior tenía TTL 600) lo empujó a gioser aunque el autoritativo ya dijera la caja. Hacían falta las dos condiciones a la vez. Recuperados con un push del ref exacto desde el clon local; la UI del nuevo ya muestra `02a9535f`. Segunda pasada: 845/845 y una sola diferencia, la esperada. En metadatos, `action` tenía tres filas posteriores al snapshot (los mismos dos repos) y CERO issues/comentarios/releases. El orden para el resto de la mudanza: bajar el TTL ANTES del corte · apagar el origen de verdad (los dos supervisores) ANTES de tocar el DNS · comparar refs después, siempre · y dejar el origen apagado un rato antes de borrarlo, precisamente para poder comparar. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn --- docs/28-servidor-de-produccion.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md index 852c8917..4c70f1de 100644 --- a/docs/28-servidor-de-produccion.md +++ b/docs/28-servidor-de-produccion.md @@ -1216,6 +1216,35 @@ perfecta. Pasó en las dos máquinas antes de mirar el script (`SB_PORT=23`). **Pendiente**: que ese respaldo sea periódico, no de una vez. Es un renglón en el cron de la caja. +### 6.16 ⚠ SÍ se perdieron dos commits en la ventana — y cómo se detectó + +La pregunta correcta después de un cutover no es «¿arrancó?» sino **«¿entró algo en el viejo +mientras tanto?»**. Se contesta comparando **todos los refs de los dos lados**: + +```sh +for r in /*/*.git; do git -C "$r" for-each-ref --format="$r %(refname) %(objectname)"; done | sort +``` + +845 refs a cada lado, y **dos diferencias**. Una era esperada (`sergio/takana` main, el nuevo por +delante con los commits posteriores al corte — `merge-base --is-ancestor` confirma fast-forward). La +otra **no**: `tawasuyu/tawasuyu` tenía en el VIEJO dos commits que el nuevo no tenía — +`b69008eb` (freebsd) y `02a9535f` (shuma, **19:48**)—, o sea **quince minutos después del snapshot +final**. + +**Por qué entraron**: el gitea viejo había resucitado (§6.15, OpenRC) y un cliente con el DNS +**cacheado** —el CNAME anterior tenía TTL 600— lo empujó a gioser aunque el autoritativo ya dijera +la caja. Las dos condiciones a la vez: un origen que revive y una caché que todavía apunta. + +**Recuperados** con un `git push` del ref exacto desde el clon local al gitea nuevo; la UI del nuevo +ya muestra `02a9535f`. Segunda pasada de comparación: **845/845 y una sola diferencia, la esperada**. +Y del lado de los metadatos, `action` tenía tres filas posteriores al snapshot (los mismos dos +repos) y **cero** issues, comentarios o releases: no se perdió nada que no fueran esos commits. + +**La lección para el resto de la mudanza**, en orden: (1) bajar el TTL **antes** del corte, no +durante; (2) apagar el origen de verdad —los DOS supervisores— **antes** de tocar el DNS; (3) +comparar refs después, siempre, porque es la única prueba de que no se perdió nada; y (4) dejar el +origen apagado un rato **antes** de borrarlo, precisamente para poder hacer esta comparación. + ## 7. Reusar los scripts que ya existen, y no escribir de nuevo Pedido explícito del usuario. El inventario de lo que ya hace el trabajo: