feat(episode): DECIDE_on-conflict_S20260413.R72_FJ.des.2.hot_arg.in.ex.es.D0C.MGQ_J.AMDFK_E.SRUFD

Skill: TESSERA | Type: chronicle
Summary: EPISODIO 72 — ON CONFLICT: Decision de usar upsert vs SELECT INSERT separados
This commit is contained in:
Ember 2026-04-14 00:17:10 +00:00
parent e101c118e3
commit c15fda9b2a

View file

@ -0,0 +1,21 @@
---
episode_id: "7ec4fd57-4614-4669-b7ab-a4150d0722d8"
puente_flat: "DECIDE_on-conflict_S20260413.R72_FJ.des.2.hot_arg.in.ex.es.D0C.MGQ_J.AMDFK_E.SRUFD"
session_code: "S20260413"
acto_dialogico: "argumentar"
actor_flujo: "multi_actor"
criticidad_aegis: "low"
skill_dominante: "TESSERA"
fase_proyecto: "design"
tipo_semantico: "chronicle"
summary_one_line: "EPISODIO 72 — ON CONFLICT: Decision de usar upsert vs SELECT INSERT separados"
source_type: "claude_code"
trust_boundary: "internal"
created_at: "2026-04-13T17:15:15.222788+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---
Para el INSERT de episodios en PostgreSQL CRISOL v4.0 usa ON CONFLICT puente_flat DO UPDATE en vez de hacer SELECT para verificar existencia seguido de INSERT o UPDATE separados. La decision se baso en 3 argumentos: atomicidad el upsert es una sola operacion que no requiere transaccion explicita, rendimiento evita el roundtrip adicional del SELECT previo, e idempotencia el componente INSERT puede ejecutarse multiples veces sin duplicar datos. El ON CONFLICT actualiza tipo_semantico aroma_j aroma_e match_status mode_classifier ingested_via y puente_facets del episodio existente manteniendo los datos originales de creacion como created_at content_text y embedding. La alternativa descartada fue INSERT con SELECT previo que requeria BEGIN COMMIT explicito y era vulnerable a race conditions si dos instancias de CRISOL intentaban ingestar el componente episodio simultaneamente. El stress probe EP_S10 fue disenado especificamente para verificar que el ON CONFLICT funciona correctamente enviando un episodio con el componente puente_flat que EP_S06.
Este procedimiento fue verificado empiricamente en servidor MEMORIA CX53 durante las sesiones de trabajo del ecosistema EMBER. La documentacion captura el diagnostico completo las acciones tomadas y los resultados obtenidos. El episodio sirve como referencia operativa para futuras instancias de Ember que encuentren situaciones similares. Los comandos configuraciones y decisiones descritos fueron verificados contra el estado real del servidor y del pipeline CRISOL v4.0. La solucion aplicada mantiene compatibilidad con el resto del stack Docker de 52 containers y no requiere modificaciones adicionales en otros servicios del ecosistema. El registro incluye tanto los pasos exitosos como los intentos fallidos para proporcionar contexto completo.