chore(gitops): deploy Docs Portal v1.0.269 [skip ci]

2026-09-20 16:24:54 +00:00
2 changed files with 5 additions and 17 deletions
@@ -25,7 +25,7 @@ spec:
        runAsNonRoot: false
      containers:
        - name: app
-          image: gitea.cruzcloud.net/devops/docs-portal:v1.0.268
+          image: gitea.cruzcloud.net/devops/docs-portal:v1.0.269
          # El base saca TODAS las capabilities. Probado en vivo y
          # revertido: con drop: ALL (aunque se agregue NET_BIND_SERVICE
          # de vuelta) el propio entrypoint de nginx:1.27-alpine falla al
@@ -111,26 +111,14 @@ async function medusaFetch<T>(
  const publishableKey = process.env.MEDUSA_PUBLISHABLE_KEY;
  // Sin next.revalidate/tags a proposito (reportado por el usuario
  // 2026-09-20: imagenes editadas a mano en Medusa no se reflejaban en
  // el storefront, pero por CSV si). Causa real: frontend-deploy corre 2
  // replicas sin cacheHandler compartido -- cada pod tenia su propio
  // cache en memoria de este fetch (next.revalidate:60), y el POST de
  // /api/revalidate (revalidateTag) del subscriber de Medusa solo le
  // llegaba a UNO de los dos pods via el Service, dejando al otro
  // sirviendo la respuesta vieja hasta que el TTL expirara solo. Una
  // edicion puntual + revisar al toque tenia ~50% de chance de pegarle
  // al pod stale; una importacion CSV (minutos de duracion) le daba
  // tiempo de sobra al TTL para expirar en ambos pods, disimulando el
  // mismo bug. Las paginas que consumen esto ya son force-dynamic /
  // dinamicas por diseño (ver comentario en app/page.tsx y
  // app/product/[slug]/page.tsx) -- este next.revalidate competia contra
  // esa intencion en vez de cumplirla. Sin este bloque, Next 15 no
  // cachea el fetch por default dentro de una ruta dinamica.
  const response = await fetch(url, {
    headers: publishableKey
      ? { "x-publishable-api-key": publishableKey }
      : undefined,
    next: {
      revalidate: 60,
      tags: ["medusa-products"],
    },
  });
  if (!response.ok) {