Mismo error encontrado en el gate de verificacion, ahora en la ruta
propia en vez del job de sync: "Method calculatePrices requires
currency_code in the pricing context" -- query.graph necesita
region_id/currency_code en el contexto para resolver
variants.calculated_price. El storefront ya manda region_id contra
/store/products (medusa.ts, regionId()); esta ruta ahora acepta el
mismo query param y arma el contexto de pricing con QueryContext(),
igual que la ruta oficial /store/meilisearch/products del plugin.
Encontrado en vivo (gate de verificacion de Fase 2): el job de sync
inicial del plugin fallaba en TODOS los productos con "Method
calculatePrices requires currency_code in the pricing context" --
variants.calculated_price necesita region_id/currency_code en el
contexto de query.graph, que el workflow interno del plugin
(sync-products.js) no provee. Las categorias si indexaron bien (21),
solo productos fallaba, por eso numberOfDocuments quedaba en 0 pese a
que el indice y sus settings se crearon correctamente.
variants.prices (lista cruda, sin resolver promociones/reglas de
precio) no requiere ese contexto y alcanza para el filtro/orden por
precio de la busqueda -- no necesitamos el precio final promocional
ahi, esa resolucion ya la hace la ruta /store/search via query.graph
con el contexto real al re-hidratar los productos.
Instala @rokmohar/medusa-plugin-meilisearch@^1.4.1 (linea v1, la unica
compatible con nuestro Medusa 2.18.0 exacto -- confirmado contra
peerDependencies reales de npm: @medusajs/* ^2.15.2, satisfecho por
2.18.0). Conectado via un array `plugins:` nuevo en medusa-config.ts
(primer uso en este repo, no `modules:`), env vars leidos con `?? ""`
en vez de required() -- si Meilisearch esta caido o mal configurado,
el plugin se degrada solo en vez de tumbar el arranque de Medusa
entero.
No se escribe un subscriber propio: se verifico contra el codigo
fuente real del paquete (descargado el tarball exacto de npm,
inspeccionado en /app/node_modules dentro de una imagen Docker de
verdad) que trae sus propios subscribers de product/category/
collection/variant/etc, descubiertos por Medusa en runtime desde
dentro del propio paquete -- confirmado que sobreviven a
`npm prune --omit=dev` y llegan intactos a la imagen final. Tambien
trae un job de indexado inicial de una sola corrida al boot
(numberOfExecutions: 1, no un cron recurrente -- no viola la
restriccion del ADR de "nunca cron").
Nueva ruta Store API propia (src/api/store/search/route.ts): las
rutas /store/meilisearch/* que trae el plugin no devuelven
facetDistribution (verificado leyendo su codigo fuente), asi que esta
ruta pide facets explicitamente via additionalOptions.facets, y
despues re-hidrata los productos via query.graph (mismos campos que
ya usa el storefront) en vez de confiar en precios/inventario
indexados -- mismo patron "safe path" que ya usa la ruta oficial del
plugin para /store/meilisearch/products.
Transformer custom en medusa-config.ts que espeja mapProduct() del
storefront (category/collection/brand/ageRange desde metadata,
disponibilidad desde la primera variante) para que el documento
indexado sea exactamente lo que el storefront ya muestra.
Validado en vivo: build completo de Docker (target builder) corre
limpio -- npm ci, medusa build (typecheck + compile backend/frontend),
npm prune -- cero errores. package-lock.json regenerado con un
contenedor node:22.18.0-bookworm-slim real (mismo base image que el
Dockerfile), no a mano.
Dockerfile: dummy MEILISEARCH_HOST/MEILISEARCH_API_KEY en el stage de
build (insurance barata, no son required() asi que no eran
estrictamente necesarios para que el build pasara, y de hecho paso
sin ellos en la prueba -- se dejan de todas formas por consistencia
con el resto de dummies de esa capa).
/store/products descarta en silencio la relacion +categories aunque
/admin/products si la expone (bug real, no teorico, confirmado en la
auditoria de Fase 5 con las 21 categorias y 9 productos [DEMO]
creados en Etapa 1 -- todos caian a "Variedades" pese a tener
categoria real asignada). Middleware global sobre req.allowed, patron
oficial de Medusa v2 para ampliar campos de una ruta core restringida.
Etapa 2, sub-fase 1 (categorias/colecciones reales) de
docs/decisiones/0005-rediseno-storefront.md.
El fix de CVE-2026-59873 (rm -rf npm entero, mergeado en
fix/devsecops-medusa-cve-remediation) rompio en produccion el init
container "migrations" de workloads/ecommerce/commerce/medusa.yaml,
que corria "npx medusa db:migrate" contra la misma imagen. Detectado
revisando el estado real del cluster despues del deploy (kubectl get
pods): medusa-deploy quedo atascado en Init:CrashLoopBackOff con
"npx: executable file not found in $PATH".
Se probo primero borrar solo el tar vendorizado dentro de npm (en vez
de npm entero) para no tocar npx -- no alcanza: el propio npx depende
de ese mismo tar internamente (pacote/arborist), asi que sigue roto
igual ("Cannot find module 'tar'"), confirmado localmente.
Fix real: mantener el rm -rf de npm completo (sin CVE), y cambiar el
init container para invocar el CLI de Medusa directo con node, sin
pasar por npx -- mismo patron que ya usa el CMD de runtime de esta
misma imagen. Verificado localmente: build OK, "node .../cli/dist/index.js
db:migrate --help" funciona sin npm/npx presentes, Trivy en exit 0.
Run 138 de build-medusa.yaml encontro 5 CVE CRITICAL reales (no falsos
positivos) al escanear la imagen con Trivy:
Remediados en el Dockerfile (verificado localmente con Trivy real,
exit 0):
- CVE-2026-33845 / CVE-2026-42010 (libgnutls30, base Debian): apt
upgrade puntual del paquete.
- CVE-2026-59873 (tar vendorizado dentro del npm CLI global de la
imagen base node:*-slim): se elimina /usr/local/lib/node_modules/npm
completo -- no es una dependencia real del proyecto (el CMD nunca
invoca npm en runtime), asi que no hay nada que "actualizar".
Documentados como excepcion en workloads/commerce-backend/.trivyignore
(con --ignorefile solo en este workflow, no afecta a build.yaml ni
deploy-docs.yaml):
- CVE-2024-24790 / CVE-2025-68121 (Go stdlib embebido en el binario de
esbuild que trae [email protected], dependencia interna de
@medusajs/admin-sdk). Se probo el fix real (override de esbuild a
una version mas nueva) y rompio el build del admin panel --
[email protected] fija "esbuild: ^0.21.3" como dependencia directa, y
esbuild >=0.24 cambio el manejo de targets de transpilacion que vite
5 espera. No existe un patch dentro de la serie 0.21.x con un Go
toolchain mas nuevo. Requiere subir @medusajs/admin-sdk/vite en un
cambio aparte, fuera de alcance de este pipeline de seguridad.
Agrega a build-medusa.yaml las mismas 6 etapas ya validadas en
build.yaml (run 134, frontend): Gitleaks, Trivy IaC, Semgrep (SAST),
Trivy imagen, Syft (SBOM) y Cosign (firma + verificación).
Ruleset de Semgrep adaptado: p/typescript + p/security-audit +
p/owasp-top-ten, sin p/react/p/nextjs -- commerce-backend es la API de
Medusa v2 (Node/TypeScript), no una app con SSR. Mismos umbrales que
el frontend: Trivy bloquea en CRITICAL, Semgrep en modo auditoría
(no bloquea todavía).
Reutiliza el mismo par de llaves Cosign del frontend (secrets ya
existentes a nivel de repo); se agrega workloads/commerce-backend/cosign.pub
con la misma llave pública para que la verificación quede local a
este workflow.
El subscriber revalidate-storefront.ts (PR #9) solo escuchaba
product.updated y los eventos de variante, asi que un producto nuevo
(product.created) o eliminado (product.deleted) no disparaba
revalidateTag: el storefront tardaba hasta el ciclo normal de cache
(~60s por pod) en reflejar altas/bajas de catalogo, a diferencia de
precio/descripcion/imagenes en productos existentes, que ya viajan por
product.updated.
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.
Todos los Ingress del lab terminan en Traefik por HTTP plano (entrypoint
web, sin TLS); Cloudflare es quien atiende HTTPS de cara al navegador.
Con secure:true (default en produccion), express-session nunca emite
Set-Cookie porque no detecta la conexion como HTTPS, dejando el
dashboard admin con 401 en /admin/users/me pese a loguear bien.
devops