Compare commits
6
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
5773154db9 | ||
|
|
553b1c7a32 | ||
|
|
d9c39ba2a1 | ||
|
|
164223e844 | ||
|
|
ee327b420c | ||
|
|
6c6303cf8e |
No files matched your search
@@ -25,7 +25,7 @@ spec:
|
||||
runAsNonRoot: false
|
||||
containers:
|
||||
- name: app
|
||||
image: gitea.cruzcloud.net/devops/docs-portal:v1.0.267
|
||||
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
|
||||
|
||||
@@ -26,11 +26,11 @@ spec:
|
||||
runAsUser: 1001
|
||||
containers:
|
||||
- name: app
|
||||
image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.266
|
||||
image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.270
|
||||
env:
|
||||
# Ver comentario en workloads/ecommerce/frontend/patches/deployment.yaml
|
||||
- name: APP_VERSION
|
||||
value: v1.0.266
|
||||
value: v1.0.270
|
||||
- name: HEADLESS_PROVIDER
|
||||
value: medusa
|
||||
# Backend COMPARTIDO con Producción a propósito (decisión del
|
||||
|
||||
@@ -111,14 +111,26 @@ 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) {
|
||||
|
||||
Reference in new issue
Block a user