Merge pull request 'docs(playbooks): documentar incidentes túnel/precios/imágenes' (#13) from fix/docs-incidentes-tunel-precios-imagenes into main

Tres incidentes resueltos en la sesión del 2026-08-12/13: 504 intermitente
por QUIC inestable en cloudflared, precios null por falta de region_id
en el Store API de Medusa v2 (se descarta la hipótesis inicial de
regiones COP duplicadas con evidencia directa en Postgres), e imágenes
en blanco por un proxy host mal configurado en Nginx Proxy Manager para
media.cruzcloud.net. Se agregan también dos notas de referencia en
known-issues.md: la topología Cloudflare Tunnel -> NPM -> k3d, y el
requisito de region_id explícito en StoreGetProductsParams.

docs/known-issues.md

@@ -42,3 +42,56 @@ Ajustar el MTU del cluster k3d a un valor seguro (`1400`) de forma
 consistente en la red Docker del cluster y en flannel, para eliminar el
 blackhole de raíz y poder quitar el `podAffinity` (o dejarlo como
 optimización, no como requisito de disponibilidad).
+
+## Topología de red: Cloudflare Tunnel → Nginx Proxy Manager → k3d
+
+**Estado:** referencia de arquitectura — no es un issue abierto, pero el
+patrón de falla que describe ya se repitió una vez (ver
+`docs/playbooks/incidente-medusa-imagenes-proxy-npm-2026-08.md`) y puede
+volver a aparecer con otro subdominio.
+
+**Ruta real de una petición pública a `*.cruzcloud.net`:**
+
+```
+Internet → Cloudflare (DNS proxied, túnel) → contenedor `cloudflared`
+  (app nativa de ZimaOS, red Host) → Nginx Proxy Manager
+  (contenedor `nginxproxymanager`, config en
+  /DATA/AppData/nginxproxymanager/data/) → 192.168.68.61:90
+  → `k3d-lab-cluster-serverlb` (k3d-proxy, publica 90→80 y 9443→443)
+  → Traefik (ingress del cluster) → Service correspondiente,
+  enrutado por el header `Host`.
+```
+
+Los proxy hosts de NPM viven en
+`/DATA/AppData/nginxproxymanager/data/database.sqlite` (tabla
+`proxy_host`) y NPM regenera solo el `.conf` correspondiente en
+`data/nginx/proxy_host/<id>.conf` cuando cambia la fila en la base —
+no hace falta editar el `.conf` a mano, y si se edita a mano puede
+sobreescribirse en cualquier cambio posterior desde la UI/DB.
+
+**Patrón de diagnóstico:** si un subdominio `*.cruzcloud.net` responde
+`500 Internal Server Error` con header `Server: openresty` cuando se
+accede públicamente, pero el mismo path funciona bien contra el
+ingress interno del cluster (`curl -H "Host: <subdominio>"
+http://<IP-del-nodo>/...`), el problema **no está en el cluster ni en
+la app** — está en el proxy host de NPM para ese subdominio. Revisar
+`forward_host`/`forward_port` en la tabla `proxy_host` y compararlos
+contra un host que sí funcione (ej. `shop.cruzcloud.net`,
+`commerce.cruzcloud.net`, ambos con `forward_host='192.168.68.61'`,
+`forward_port=90`).
+
+## Nota de arquitectura: Medusa v2 Store API requiere `region_id` explícito
+
+**Estado:** no es un issue, es un requisito de la API que causó un
+incidente real por no ser conocido — ver
+`docs/playbooks/incidente-medusa-precios-region-id-2026-08.md`.
+
+El endpoint `/store/products` de Medusa v2 (validado por
+`StoreGetProductsParams`, `.strict()`) **no acepta `currency_code` ni
+`country_code`** como parámetros para resolver el contexto de precio
+(`calculated_price`). El único parámetro válido para ese fin es
+`region_id`, apuntando a una región existente y configurada vía Admin
+API. Cualquier integración nueva contra el Store API de Medusa v2 que
+necesite precios calculados debe pasar `region_id` explícito — no
+asumir que `currency_code` o `country_code` son suficientes, aunque lo
+sean en Medusa v1 o en otras APIs de e-commerce.

docs/playbooks/incidente-cloudflared-504-quic-2026-08.md

@@ -0,0 +1,52 @@
+# Incidente: 504 Gateway Timeout intermitente en gitea.cruzcloud.net (túnel QUIC inestable) (2026-08)
+
+**Ventana del incidente:** intermitente durante varias horas, 2026-08
+**Servicio afectado:** `cloudflared` (túnel de Cloudflare, app nativa de ZimaOS, modo red Host) — afecta a todos los subdominios servidos por el mismo túnel (`gitea.cruzcloud.net`, `commerce.cruzcloud.net`, `shop.cruzcloud.net`, `media.cruzcloud.net`, Immich, Argo CD, Memos, etc.)
+**Impacto:** 504 Gateway Timeout intermitente en peticiones HTTP a cualquier host detrás del túnel, sin patrón evidente de horario ni de carga.
+
+## Síntoma
+
+`gitea.cruzcloud.net` devolvía `504 Gateway Timeout` de forma intermitente. El mismo síntoma se observaba en otros hosts servidos por el mismo túnel (Immich, Argo CD, Memos), lo que apuntaba a una causa compartida a nivel de túnel, no de una app individual.
+
+## Diagnóstico
+
+```
+docker logs -f cloudflared 2>&1 | grep -i -E "connIndex|protocol|retry"
+```
+
+Reveló un patrón sostenido durante horas: la conexión `connIndex=2` (de las 4 conexiones que `cloudflared` mantiene hacia el edge de Cloudflare) sufría fallos recurrentes de "control stream" cada 2-6 minutos, reconectándose en loop:
+
+```
+control stream encountered a failure while serving
+Retrying connection in up to 1m4s
+```
+
+Cuando una petición HTTP coincidía con el instante exacto de una de esas caídas de `connIndex=2`, el cliente recibía el 504.
+
+## Causa raíz
+
+El contenedor `cloudflared` (imagen oficial `cloudflare/cloudflared:latest`) usaba **QUIC (UDP)** como protocolo de transporte por defecto para sus 4 conexiones hacia el edge de Cloudflare. Una de esas conexiones presentaba fallos de control stream recurrentes durante horas.
+
+Causa de fondo probable: inestabilidad de UDP/QUIC en la red local (NAT/firewall doméstico). QUIC es más sensible que TCP/HTTP2 a NATs agresivos o middleboxes que no manejan bien tráfico UDP de larga vida — un patrón común en redes domésticas, a diferencia de datacenters con NAT dedicado para este tipo de tráfico.
+
+## Fix aplicado
+
+Se agregó la variable de entorno `TUNNEL_TRANSPORT_PROTOCOL=http2` en la configuración del contenedor `cloudflared` desde la app de ZimaOS (sección Ambiente → variables), forzando HTTP/2 sobre TCP en vez de QUIC/UDP.
+
+Tras reiniciar el contenedor, el precheck de `cloudflared` confirmó:
+
+```
+Environment is healthy. cloudflared will use 'http2' as primary protocol.
+```
+
+y las 4 conexiones pasaron a `protocol=http2`.
+
+## Validación
+
+Curl en loop contra `gitea.cruzcloud.net` tras el cambio: latencia estable ~0.37–0.4s sostenida por 24+ minutos sin un solo 504.
+
+## Nota — degradación puntual no relacionada, pendiente de vigilar
+
+Durante la ventana de validación se observó una ventana breve de latencia alta (hasta 39s) y algunos `502`/`530`, coincidiendo con una ejecución pesada de Gitea Actions (build/deploy de Medusa) en el mismo host. Esto es contención de recursos local (CPU/IO del host compitiendo entre el runner de Actions y el resto de los servicios), **no relacionado al fix de protocolo del túnel** — no se reabrió como parte de este incidente.
+
+**Pendiente:** vigilar si estas ventanas de degradación coinciden sistemáticamente con builds/deploys de Gitea Actions. Si es recurrente, considerar mover el runner (`gitea-runner`) a otro host o limitarle recursos (CPU/memoria) para evitar que compita con el resto de las apps del NAS.

docs/playbooks/incidente-medusa-imagenes-proxy-npm-2026-08.md

@@ -0,0 +1,63 @@
+# Incidente: imágenes de producto en blanco en el storefront (proxy host de media.cruzcloud.net mal configurado en NPM) (2026-08)
+
+**Ventana del incidente:** 2026-08-13, resuelto el mismo día
+**Servicio afectado:** `media.cruzcloud.net` (Nginx Proxy Manager → MinIO, `minio-svc` en namespace `ecommerce`)
+**Impacto:** las imágenes subidas a productos desde el Admin de Medusa no se visualizaban en el detalle de producto del storefront (`shop.cruzcloud.net`) — el resto del producto (título, precio, subtítulo, botón añadir al carrito) se renderizaba bien.
+
+## Síntoma
+
+Al agregar imágenes a un producto desde el Admin de Medusa (sección Media), estas se veían correctamente cargadas en el Admin, pero en la página de detalle de producto del frontend los thumbnails aparecían vacíos/en blanco.
+
+## Diagnóstico
+
+1. **Storage:** confirmado que Medusa usa el provider `@medusajs/medusa/file-s3` apuntando a MinIO interno (`S3_ENDPOINT=http://minio-svc:9000`, bucket `ari-products`), con URLs públicas construidas sobre `S3_FILE_URL=https://media.cruzcloud.net/ari-products` (env en configmap `commerce-config`, namespace `ecommerce`).
+2. **API:** el producto traía URLs absolutas válidas, ej. `https://media.cruzcloud.net/ari-products/<archivo>.jpg`.
+3. **Prueba directa de la URL:**
+   - Contra el ingress interno del cluster (bypaseando el proxy externo, `Host: media.cruzcloud.net` directo a la IP del `k3d-proxy`) → `200 OK`, MinIO sirve el JPEG correctamente.
+   - Contra `https://media.cruzcloud.net/...` (la ruta real que usa el navegador del cliente, vía Cloudflare) → `500 Internal Server Error`, `Server: openresty`.
+
+Ese contraste (funciona interno, falla público, con `Server: openresty` — el motor de Nginx Proxy Manager) aisló el problema al proxy externo, no a Medusa/MinIO/frontend.
+
+## Causa raíz
+
+En Nginx Proxy Manager (`/DATA/AppData/nginxproxymanager/`, contenedor `nginxproxymanager`), el proxy host de `media.cruzcloud.net` (`id=13` en la tabla `proxy_host` de `database.sqlite`) estaba mal configurado:
+
+```
+forward_host = "http://192.168.68.61/"   -- esquema y barra final metidos dentro del campo (formato inválido)
+forward_port = 5005                       -- puerto donde no escucha ningún proceso en el host
+```
+
+Los proxy hosts que sí funcionan (`shop.cruzcloud.net` id 23, `commerce.cruzcloud.net` id 28) apuntan correctamente a:
+
+```
+forward_host = "192.168.68.61"
+forward_port = 90   -- puerto publicado por k3d-lab-cluster-serverlb hacia Traefik
+```
+
+Se confirmó con `ss`/`docker ps` en el host que nada escuchaba en el puerto `5005` — este proxy host nunca estuvo apuntando correctamente al cluster, muy probablemente un typo desde que se creó.
+
+## Fix aplicado
+
+1. Backups previos: `database.sqlite.bak-pre-media-fix` y `13.conf.bak-pre-media-fix`.
+2. Corrección directa en la base SQLite de NPM:
+   ```sql
+   UPDATE proxy_host SET forward_host='192.168.68.61', forward_port=90 WHERE id=13;
+   ```
+3. NPM regeneró automáticamente `nginx/proxy_host/13.conf` con los valores correctos (la app Node de NPM detecta el cambio en la base y reescribe el `.conf`; no hace falta editarlo a mano).
+4. Recarga de nginx dentro del contenedor:
+   ```
+   docker exec nginxproxymanager nginx -t
+   docker exec nginxproxymanager nginx -s reload
+   ```
+
+Adicionalmente, se seteó el campo `thumbnail` del producto de prueba desde el Admin (estaba en `null`) — Medusa no lo autocompleta a partir del array `images`, y el frontend lo usa como imagen hero en listados/tarjetas de catálogo.
+
+## Validación
+
+Confirmado visualmente en `shop.cruzcloud.net/product/cybertron-sentinel-figura-de-coleccion-test-revalidate` que tanto la galería del detalle como el thumbnail en listados/tarjetas se renderizan correctamente. También se validó que ediciones de descripción/título/precio desde el Admin se reflejan automáticamente en el storefront sin necesidad de restart ni intervención manual, vía el subscriber `revalidate-storefront.ts` (`workloads/commerce-backend/src/subscribers/`) que procesa el evento `product.updated` de Medusa.
+
+## Lecciones aprendidas
+
+**Aislar interno vs. público antes de sospechar de la app.** Medusa, MinIO y el frontend estaban sanos todo el tiempo — la falla estaba en una capa de infraestructura fuera de los repos de GitOps (Nginx Proxy Manager, gestionado por fuera de `apps-registry`/`platform-infra`, sin versionar). Comparar la misma petición por la ruta interna del cluster contra la ruta pública real fue lo que aisló la causa en minutos, sin necesidad de tocar Medusa ni el frontend.
+
+Ver `docs/known-issues.md` para la topología completa Cloudflare Tunnel → Nginx Proxy Manager → k3d y el patrón a seguir si otro subdominio (`*.cruzcloud.net`) presenta el mismo síntoma (`500`/`Server: openresty` público pero sano internamente).

docs/playbooks/incidente-medusa-precios-region-id-2026-08.md

@@ -0,0 +1,66 @@
+# Incidente: precios `null` en detalle de producto (Medusa Store API sin region_id) (2026-08)
+
+**Ventana del incidente:** 2026-08-12, resuelto el mismo día (commit `60072cf`)
+**Servicio afectado:** `medusa-svc` (Store API), consumido por el frontend Next.js de ARI Shopping
+**Impacto:** en el listado de productos (`/catalog`) los precios se mostraban correctamente, pero en la página de detalle de producto individual varios artículos mostraban "Consultar precio" en vez del monto real.
+
+## Hipótesis inicial descartada: regiones COP duplicadas
+
+La primera hipótesis fue que existían regiones "Colombia (COP)" duplicadas en Medusa, causando ambigüedad al resolver el precio. Se descartó con evidencia directa en Postgres, consultando la tabla `region` **incluyendo soft-deletes**:
+
+```sql
+SELECT id, name, currency_code, created_at, updated_at, deleted_at FROM region ORDER BY created_at;
+
+               id                |   name   | currency_code |         created_at         |         updated_at         | deleted_at
+----------------------------------+----------+---------------+----------------------------+----------------------------+------------
+ reg_01KZT86WPAH7A7ZZRDSX3350V2  | Colombia | cop           | 2026-08-12 05:48:03.151+00 | 2026-08-12 05:48:03.151+00 |
+(1 row)
+```
+
+Una sola fila, creada una sola vez, nunca actualizada, nunca borrada (`deleted_at` vacío). **No había ni hubo nunca una región duplicada** — la hipótesis de deduplicación quedó descartada con esta consulta.
+
+## Causa raíz real
+
+El backend de Medusa **no tenía ninguna región configurada**. El frontend pedía precios al Store API (`/store/products`) usando el parámetro `currency_code=cop`, pero el validador `StoreGetProductsParams` de Medusa v2 (`.strict()`) **no acepta ese campo** — devolvía `400 Unrecognized fields: 'currency_code'` en cada carga de `/catalog`.
+
+Se probó también `country_code`, que tampoco funcionó — Medusa respondía:
+
+```
+Missing required pricing context to calculate prices - region_id
+```
+
+**Medusa v2 requiere explícitamente un `region_id` válido** para poder calcular precios (`calculated_price`) vía Store API; ni `currency_code` ni `country_code` son parámetros válidos para ese fin.
+
+## Fix aplicado
+
+Commit `60072cf` — *"fix: usar region_id en vez de currency_code para precios de Medusa"* (PR #5, mergeado en `04dc6bd`):
+
+1. Se creó la región "Colombia" (moneda COP) vía Admin API — no existía ninguna región configurada previamente.
+2. Se modificó el frontend para pedir precios usando `region_id` explícito en vez de `currency_code`, vía una nueva variable de entorno `MEDUSA_REGION_ID`:
+
+```diff
+# workloads/ecommerce/frontend.yaml
+         - name: MEDUSA_BACKEND_URL
+           value: http://medusa-svc:9000
++        - name: MEDUSA_REGION_ID
++          value: reg_01KZT86WPAH7A7ZZRDSX3350V2
+```
+
+```diff
+# workloads/ecommerce/lib/headless/providers/medusa.ts
+   const params = new URLSearchParams({
+     limit: String(limit),
+-    currency_code: "cop",
++    // El validador de /store/products no acepta currency_code (400
++    // "Unrecognized fields"); el precio calculado solo se resuelve con
++    // region_id.
++    region_id: regionId(),
+```
+
+No hubo migración de precios entre regiones — no existían datos previos que migrar; la región se creó de cero como parte de este mismo fix. `MEDUSA_REGION_ID` no ha cambiado desde el commit original (verificado con `git log -p --follow` sobre `frontend.yaml`), y sigue apuntando a la única región que existe en la base.
+
+## Lecciones aprendidas
+
+**Verificar la causa raíz contra el estado real de la base de datos antes de asumir la primera hipótesis**, aun cuando esa hipótesis coincida con la intuición inicial de quien reporta el bug ("puede que haya algo duplicado"). La consulta a `region` incluyendo `deleted_at` tomó segundos y evitó documentar una causa raíz incorrecta en este mismo playbook.
+
+**Nota de arquitectura:** Medusa v2 Store API (`StoreGetProductsParams`) requiere `region_id` explícito para resolver precios calculados. `currency_code` y `country_code` no son parámetros válidos para ese fin — ver también `docs/known-issues.md`.

workloads/commerce-backend/src/subscribers/revalidate-storefront.ts

@@ -0,0 +1,46 @@
+import type { SubscriberArgs, SubscriberConfig } from "@medusajs/framework";
+import { ContainerRegistrationKeys } from "@medusajs/framework/utils";
+
+export default async function revalidateStorefrontHandler({
+  container,
+}: SubscriberArgs) {
+  const logger = container.resolve(ContainerRegistrationKeys.LOGGER);
+
+  const storefrontUrl = process.env.STOREFRONT_URL;
+  const secret = process.env.REVALIDATE_SECRET;
+
+  if (!storefrontUrl || !secret) {
+    logger.warn(
+      "STOREFRONT_URL o REVALIDATE_SECRET no configurados; se omite la revalidación del storefront.",
+    );
+    return;
+  }
+
+  try {
+    const response = await fetch(`${storefrontUrl}/api/revalidate`, {
+      method: "POST",
+      headers: { "x-revalidate-secret": secret },
+    });
+
+    if (!response.ok) {
+      logger.warn(
+        `Revalidación del storefront respondió HTTP ${response.status}.`,
+      );
+    }
+  } catch (error) {
+    logger.warn(
+      `No se pudo revalidar el storefront: ${(error as Error).message}`,
+    );
+  }
+}
+
+export const config: SubscriberConfig = {
+  event: [
+    "product.created",
+    "product.updated",
+    "product.deleted",
+    "product-variant.updated",
+    "product-variant.created",
+    "product-variant.deleted",
+  ],
+};

workloads/ecommerce/app/api/revalidate/route.ts

@@ -0,0 +1,13 @@
+import { revalidateTag } from "next/cache";
+
+export async function POST(request: Request) {
+  const secret = request.headers.get("x-revalidate-secret");
+
+  if (!secret || secret !== process.env.REVALIDATE_SECRET) {
+    return Response.json({ message: "Invalid secret" }, { status: 401 });
+  }
+
+  revalidateTag("medusa-products");
+
+  return Response.json({ revalidated: true, tag: "medusa-products" }, { status: 200 });
+}

workloads/ecommerce/commerce/medusa.yaml

@@ -52,7 +52,7 @@ spec:
               memory: 64Mi
 
         - name: migrations
-          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.88
+          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.92
           imagePullPolicy: IfNotPresent
           command:
             - npx
@@ -73,7 +73,7 @@ spec:
 
       containers:
         - name: medusa
-          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.88
+          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.92
           imagePullPolicy: IfNotPresent
           envFrom:
             - configMapRef:

workloads/ecommerce/commerce/secrets.template.yaml

@@ -22,6 +22,11 @@ stringData:
 
   JWT_SECRET: CAMBIAR
   COOKIE_SECRET: CAMBIAR
+
+  # Debe ser el MISMO valor que REVALIDATE_SECRET en el Secret
+  # commerce-storefront: el subscriber de Medusa lo envía como header
+  # x-revalidate-secret al invocar POST /api/revalidate en el storefront.
+  REVALIDATE_SECRET: CAMBIAR
 ---
 apiVersion: v1
 kind: Secret
@@ -30,3 +35,6 @@ metadata:
 type: Opaque
 stringData:
   MEDUSA_PUBLISHABLE_KEY: pk_CAMBIAR_DESPUES_DE_CREARLA_EN_MEDUSA
+
+  # Mismo valor que REVALIDATE_SECRET en commerce-secrets.
+  REVALIDATE_SECRET: CAMBIAR

workloads/ecommerce/frontend.yaml

@@ -16,7 +16,7 @@ spec:
       - name: gitea-registry-secret
       containers:
       - name: web
-        image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.87
+        image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.91
         ports:
         - containerPort: 80
         env: