feat(episode): BACKFILL_q-59afbe6b-cf7a-5a69-9fe6-a1152dd39e6c_S20260413_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.364E0_E.6C7-5

Skill: NONE | Type: chronicle
Summary: ** El síntoma que describes — timeout en el endpoint `/healthz` de Qdrant en MEM

episodes/BACKFILL_q-59afbe6b-cf7a-5a69-9fe6-a1152dd39e6c_S20260413_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.364E0_E.6C7-5.md

@@ -0,0 +1,19 @@
+---
+episode_id: "364e06c7-5b60-5b1f-934b-7b5549fe8930"
+puente_flat: "BACKFILL_q-59afbe6b-cf7a-5a69-9fe6-a1152dd39e6c_S20260413_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.364E0_E.6C7-5"
+session_code: "S20260413"
+acto_dialogico: "informar"
+actor_flujo: "ember_internal"
+criticidad_aegis: "moderate"
+skill_dominante: "NONE"
+fase_proyecto: "maintenance"
+tipo_semantico: "chronicle"
+summary_one_line: "** El síntoma que describes — timeout en el endpoint `/healthz` de Qdrant en MEMORIA CX53 después de un reinicio de kernel — apunta a un problema de conectividad interna entre Caddy (reverse proxy) y"
+source_type: "claude_code"
+trust_boundary: "default"
+created_at: "2026-05-10T00:00:00+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+** El síntoma que describes — timeout en el endpoint `/healthz` de Qdrant en MEMORIA CX53 después de un reinicio de kernel — apunta a un problema de conectividad interna entre Caddy (reverse proxy) y el container de Qdrant, no a un fallo del propio Qdrant. Primer paso del diagnóstico: verificar si Qdrant responde internamente sin pasar por Caddy. El comando `docker exec qdrant curl -s http://localhost:6333/healthz` ejecutado directamente dentro del container de Qdrant permite aislar si el problema está en Qdrant o en la capa de red entre Caddy y Qdrant. **John:** OK, ejecuté ese resultado. Qdrant responde `{"title":"qdrant - vectorass engine","version":"1.12.1","status":"ok"}` dentro del container. Así que Qdrant está vivo. **Ember:** Confirmado: Qdrant funciona correctamente dentro de su container en MEMORIA CX53. El fallo no está en Qdrant sino en la ruta de red entre Caddy y el container. Después de un reinicio de kernel, Docker recrea las interfaces de red virtuales. Si Caddy se levantó antes que las redes de Docker terminaran de inicializarse, Caddy resolvió la IP interna de Qdrant a una dirección que ya no existe. Segundo paso: verificar la red Docker. Necesito que ejecutes `docker network inspect ember-net | grep -A 5 qdrant` para ver la IP actual asignada al container de Qdrant en la red ember-net de MEMORIA CX53. **John:** La IP actual es 172.18.0.7. Pero en los logs de Caddy veo que está intentando conectar a 172.18.0.4. No coinciden. **Ember:** Ese es el diagnóstico. Caddy cachea las resoluciones DNS internas de Docker. Cuando MEMORIA CX53 se reinició, Docker asignó nuevas IPs a los containers (Qdrant pasó de 172.18.0.4 a 172.18.0.7). Caddy no se reinició después del reinicio de Docker, así que sigue usando la IP vieja 172.18.0.4 que ya no apunta a ningún container activo. No es un problema de configuración permanente — es una condición de carrera temporal entre Docker y Caddy durante el boot de MEMORIA CX53. El siguiente bloque de comandos reinicia Caddy para forzar re-resolución DNS sin afectar otros servicios en MEMORIA CX53: ```bash docker restart caddy && sleep 5 && curl -s https://qdrant.brasaluz.com/healthz ``` **John:** Ejecuté el reinicio de Caddy. Ahora `/healthz` responde OK con status 200. Pero vi algo raro en los logs de Docker durante el diagnóstico: hay un proceso que aparece como "phantom" en `docker top qdrant` que no debería estar ahí. ¿Es un proceso fantasma del reinicio? **Ember:** Lo que describes como "Phantom" en el...