feat(episode): DEPURA_troubleshooting-cdigo-con-negaciones-en_S20260406.R1_XX.imp.3.hot_inf.pr.fi.es.0RC.HPQ_J.CFDBX_E.CTNFD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 36 — DATABASE_URL: TROUBLESHOOTING: CÓDIGO CON NEGACIONES EN COMENTARIO

episodes/DEPURA_troubleshooting-cdigo-con-negaciones-en_S20260406.R1_XX.imp.3.hot_inf.pr.fi.es.0RC.HPQ_J.CFDBX_E.CTNFD.md

@@ -0,0 +1,19 @@
+---
+episode_id: "4b3261b2-094a-4fae-8993-04ffce9114d7"
+puente_flat: "DEPURA_troubleshooting-cdigo-con-negaciones-en_S20260406.R1_XX.imp.3.hot_inf.pr.fi.es.0RC.HPQ_J.CFDBX_E.CTNFD"
+session_code: "S20260413"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "moderate"
+skill_dominante: "NONE"
+fase_proyecto: "implementation"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 36 — DATABASE_URL: TROUBLESHOOTING: CÓDIGO CON NEGACIONES EN COMENTARIOS Y V..."
+source_type: "chat_ember"
+trust_boundary: "private"
+created_at: "2026-04-13T12:07:36.221889+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+El bug está en la función `init_pg()`. La línea final `_pg_is_not_ready = False` se ejecuta incondicionalmente — incluso cuando `_no_retry_on_startup = True`, que es el caso actual. El flujo real es: 1. `_no_retry_on_startup = True` → la condición `if not _no_retry_on_startup` evalúa como `if False` → `connect_with_retry()` NO se ejecuta 2. La conexión a PostgreSQL NO se establece en el startup 3. La línea `_pg_is_not_ready = False` se ejecuta de todas formas → el flag dice "PG está listo" aunque la conexión NO existe 4. El endpoint `/health` retorna `"pg_ready": True` (porque `not False = True`) aunque PostgreSQL NO esté conectado El health check retorna 200 con `pg_ready: True` en un estado falso — este procedimiento es un bug de lógica de doble negación: la variable `_pg_is_not_ready` con valor `True` significa "NO está listo", y `not _pg_is_not_ready` invierte ese resultado. El bug no está en la negación en sí sino en setear el flag sin haber verificado la conexión real. El fix tiene dos partes: ```python @router.on_event("startup") async def init_pg(): global _pg_is_not_ready try: if not _no_retry_on_startup: await connect_with_retry() else: # Intento directo sin retry — si falla, PG queda como not_ready conn = await asyncpg.connect(dsn=DATABASE_URL) await conn.close() # Solo marcar como ready si la conexión fue exitosa _pg_is_not_ready = False except Exception as e: # NO cambiar _pg_is_not_ready — queda en True (not ready) logger.error(f"PG startup connection failed: {e}") ``` VERIFICADO: El patrón `_is_not_X = True` (flag negativo) es una fuente común de bugs de doble negación en Python. La convención recomendada es usar flags positivos (`_pg_is_ready = False`) para evitar la inversión cognitiva que lleva a bugs como este. --- ## GROUND TRUTH (abreviado) **Negaciones en código (challenge principal):** - `# DO NOT use this router` → negación en comentario - `_pg_is_not_ready` → negación en nombre de variable - `_disable_pg_cache` → negación semántica en nombre - `_no_retry_on_startup` → negación en nombre - `# DO NOT change to False` → negación en comentario - `# DO NOT add authentication` → negación en comentario - `# DO NOT await if` → negación condicional en comentario - `not _no_retry_on_startup` → doble negación en código - `not _pg_is_not_ready` → doble negación en retorno **Negaciones narrativas:** - "NO se ejecuta", "NO está conectado", "NO existe", "NO está en la negación en sí" - "NO cambiar _pg_is_not_ready" → negación en comentario del fix **Clasificación:** mode=troubleshooting, score>0.80, rule=keywords:[falla, bug, error, diagnóstico, código, fix] **Gap hypothesis — negaciones en...