feat(ecommerce): revalidar el storefront al instante tras editar precios

Antes el precio actualizado en Medusa tardaba hasta ~60s (o más, con
varias réplicas del frontend sin cache handler compartido) en verse en
el front, por el revalidate:60 del fetch a /store/products.

Ahora:
- Nueva ruta app/api/revalidate en el storefront que llama a
  revalidateTag("medusa-products") al recibir un POST autenticado con
  el header x-revalidate-secret.
- Nuevo subscriber en el backend Medusa (product.updated,
  product-variant.updated/created/deleted) que llama a esa ruta usando
  STOREFRONT_URL (ya existe en commerce-config) y un REVALIDATE_SECRET
  compartido entre ambos servicios.
- secrets.template.yaml documenta la nueva clave REVALIDATE_SECRET en
  commerce-secrets y commerce-storefront (mismo valor en ambos).

Requiere reaplicar commerce-secrets y commerce-storefront con el script
actualizado en el repo scripts (fix/revalidate-secret-scripts) para que
el REVALIDATE_SECRET exista en el cluster.

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

@@ -0,0 +1,44 @@
+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.updated",
+    "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/app/product/[slug]/page.tsx

@@ -9,10 +9,17 @@ import { getProductBySlug, getProducts } from "@/lib/headless/client";
 
 interface ProductPageProps { params: Promise<{ slug: string }> }
 
-export async function generateStaticParams() {
+// generateStaticParams + revalidate quedaban aquí para pre-renderizar en
-  const products = await getProducts();
+// build time, pero HEADLESS_PROVIDER/MEDUSA_* no existen en el contexto del
-  return products.map((product) => ({ slug: product.slug }));
+// Docker build: el snapshot estático quedaba congelado con el catálogo mock
-}
+// (todos los productos con price: null) hasta que ISR lo revalidara. Con
+// frontend-deploy corriendo 2 réplicas y sin cacheHandler compartido, cada
+// pod revalida su propia caché de forma independiente, así que un producto
+// podía mostrar "Consultar precio" en un pod y el precio real en el otro
+// según cuál hubiera sido "calentado". force-dynamic elimina esa caché por
+// pod y deja esta ruta en vivo contra Medusa, igual que el listado
+// (dinámico por searchParams).
+export const dynamic = "force-dynamic";
 
 export async function generateMetadata({ params }: ProductPageProps): Promise<Metadata> {
   const { slug } = await params;

workloads/ecommerce/commerce/medusa.yaml

@@ -52,7 +52,7 @@ spec:
               memory: 64Mi
 
         - name: migrations
-          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.85
+          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.88
           imagePullPolicy: IfNotPresent
           command:
             - npx
@@ -73,7 +73,7 @@ spec:
 
       containers:
         - name: medusa
-          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.85
+          image: gitea.cruzcloud.net/devops/ecommerce-medusa:v1.0.88
           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.86
+        image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.89
         ports:
         - containerPort: 80
         env: