@decocms/blocks 7.62.0 → 7.62.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@decocms/blocks",
-  "version": "7.62.0",
+  "version": "7.62.2",
   "type": "module",
   "engines": {
     "node": ">=24"

package/src/cms/resolve.test.ts

@@ -239,6 +239,50 @@ describe("commerce loader auto-injects URL search params as props", () => {
     });
   });
 
+  it("strips tracking params from __pageUrl and never injects them as props", async () => {
+    const calls: Array<Record<string, unknown>> = [];
+    registerCommerceLoader(KEY, async (props: Record<string, unknown>) => {
+      calls.push({ ...props });
+      return null;
+    });
+
+    await resolveValue({ __resolveType: KEY, slug: "sabonete" }, undefined, {
+      url: "https://store.com/produto/sabonete/p?skuId=12345&utm_source=google&gclid=abc&srsltid=xyz",
+      path: "/produto/sabonete/p",
+    });
+
+    expect(calls[0]).toMatchObject({
+      slug: "sabonete",
+      skuId: "12345",
+      __pageUrl: "https://store.com/produto/sabonete/p?skuId=12345",
+    });
+    expect(calls[0]).not.toHaveProperty("utm_source");
+    expect(calls[0]).not.toHaveProperty("gclid");
+    expect(calls[0]).not.toHaveProperty("srsltid");
+  });
+
+  // The point of the strip: `createCachedLoader`'s default keyFn is
+  // JSON.stringify(props), so identical props mean a shared cache entry. A
+  // campaign tail used to mint a fresh one on every paid landing.
+  it("gives a paid-traffic landing the same props as the clean URL", async () => {
+    const calls: Array<Record<string, unknown>> = [];
+    registerCommerceLoader(KEY, async (props: Record<string, unknown>) => {
+      calls.push({ ...props });
+      return null;
+    });
+
+    const at = (url: string) =>
+      resolveValue({ __resolveType: KEY, slug: "sabonete" }, undefined, {
+        url,
+        path: "/produto/sabonete/p",
+      });
+
+    await at("https://store.com/produto/sabonete/p");
+    await at("https://store.com/produto/sabonete/p?utm_source=google&gclid=abc&fbclid=d");
+
+    expect(JSON.stringify(calls[1])).toBe(JSON.stringify(calls[0]));
+  });
+
   it("does NOT override a CMS-configured prop with a URL param of the same name", async () => {
     const calls: Array<Record<string, unknown>> = [];
     registerCommerceLoader(KEY, async (props: Record<string, unknown>) => {

package/src/cms/resolve.ts

@@ -5,6 +5,7 @@ import { stickyDecide } from "../sdk/experiments";
 import { parseSegmentCookie, SEGMENT_COOKIE, type StoredFlag, trafficToPct } from "../sdk/flags";
 import { withInflightTimeout } from "../sdk/inflightTimeout";
 import { normalizeUrlsInObject } from "../sdk/normalizeUrls";
+import { stripTrackingParams } from "../sdk/urlUtils";
 import { findPageByPath, loadBlocks } from "./loader";
 import { getOnBeforeResolveProps, getSection, registerOnBeforeResolveProps } from "./registry";
 import {
@@ -956,21 +957,35 @@ async function internalResolve(value: unknown, rctx: ResolveContext): Promise<un
       resolvedProps.__pagePath = rctx.matcherCtx.path;
     }
     if (rctx.matcherCtx.url) {
-      resolvedProps.__pageUrl = rctx.matcherCtx.url;
+      // Strip tracking params before anything here reaches props.
+      //
+      // The comment this replaces claimed the enrichment was "safe re: cache
+      // fragmentation" because commerce loaders run without a framework-level
+      // cache. That was wrong — `getCommerceLoader()` returns the
+      // `createCachedLoader`-wrapped functions, whose default keyFn hashes
+      // exactly these props — so a `?utm_source`/`gclid`/`srsltid` minted a
+      // fresh cache entry and made every paid-traffic landing a permanent cold
+      // miss. Measured on a production storefront: 0.2–1.5% hit rate on the
+      // default keyFn vs 73.5% on a loader that hand-rolled a key excluding it.
+      //
+      // Stripping here rather than in the keyFn covers `__pageUrl` and the
+      // param spread below in one place, and matches how the edge cache key is
+      // already normalized in workerEntry. No loader reads tracking params.
+      //
+      // Deliberately does NOT drop `__pageUrl`/`__pagePath` themselves: on a
+      // PDP the path IS the product identity (the CMS block leaves `slug`
+      // null) and on a PLP the query carries the facets. Dropping them would
+      // merge distinct results onto one entry and serve wrong content.
+      const pageUrl = stripTrackingParams(rctx.matcherCtx.url);
+      resolvedProps.__pageUrl = pageUrl;
       // Auto-inject URL search params as top-level props so loaders that
       // expect `props.skuId` / `props.q` / `props.page` (the apps-start
       // canonical shape) get them populated on direct entry (Google
       // Shopping deep links, paid ads, email campaigns). Existing values
       // from the CMS block win — URL params are a fallback, not an
       // override.
-      //
-      // Safe re: cache fragmentation: commerce loaders run through this
-      // path without a framework-level cache (the section/page cache
-      // layer hashes section.props BEFORE this enrichment in
-      // sectionLoaders.ts), so adding query params here does not
-      // fragment any cache key.
-      if (URL.canParse(rctx.matcherCtx.url)) {
-        const url = new URL(rctx.matcherCtx.url);
+      if (URL.canParse(pageUrl)) {
+        const url = new URL(pageUrl);
         for (const [k, v] of url.searchParams.entries()) {
           if (resolvedProps[k] !== undefined) continue;
           // `page` is skipped on purpose (#391): loaders that read `page`
@@ -994,7 +1009,7 @@ async function internalResolve(value: unknown, rctx: ResolveContext): Promise<un
         // upstream is wrong — surface it so the caller can fix it.
         console.warn(
           `[CMS] malformed matcherCtx.url for "${resolveType}"; ` +
-            `skipping query-param injection: ${rctx.matcherCtx.url}`,
+            `skipping query-param injection: ${pageUrl}`,
         );
       }
     }

package/src/cms/sectionLoaders.test.ts

@@ -5,6 +5,7 @@ import type { ResolvedSection } from "./resolve";
 import {
   getDegradedSections,
   isLayoutSection,
+  layoutLoaderCacheKey,
   registerCacheableSections,
   registerLayoutSections,
   registerNonCriticalSections,
@@ -531,3 +532,94 @@ describe("runSectionLoaders — batch span", () => {
     expect(perSection).toHaveLength(3);
   });
 });
+
+// ---------------------------------------------------------------------------
+// Layout section cache — device is part of the key
+// ---------------------------------------------------------------------------
+//
+// This cache holds a layout section's LOADER OUTPUT, and that is where
+// `isMobile` is born (`ctx.device`, or a loader composed with `withDevice` /
+// `withMobile`). Keyed by component path alone, the first request decided the
+// variant for everyone for 5 minutes. Measured on a real store's PDP with
+// Header/Footer layout-cached: desktop first and a mobile visitor got the
+// desktop header (`h-[90px]`); mobile first and a desktop visitor got
+// `id="header-mobile-menu"`.
+//
+// NOTE: this is a DIFFERENT cache from `resolvedLayoutCache` in `cms/resolve.ts`.
+// That one holds the CMS prop resolution and never sees `isMobile`, so putting
+// the axis there (which is what decocms/blocks#528 did) does not fix this.
+
+describe("layout section cache — device axis", () => {
+  const MOBILE = "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0) Mobile Safari";
+  const TABLET = "Mozilla/5.0 (iPad; CPU OS 17_0) Safari/605";
+  const DESKTOP = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Chrome/120 Safari/537.36";
+
+  // `layoutCache` is module-global with a 5-minute TTL and no exported reset, so
+  // a shared component key would leak entries between cases.
+  let seq = 0;
+  const req = (ua: string) => new Request("https://store.com/p", { headers: { "user-agent": ua } });
+
+  /** A layout loader that stamps what device it saw — the leak made visible. */
+  const setupDeviceLayout = () => {
+    seq += 1;
+    const key = `site/sections/DeviceLayout${seq}.tsx`;
+    let runs = 0;
+    registerSectionLoader(key, async (props: Record<string, unknown>, request?: Request) => {
+      runs += 1;
+      const ua = request?.headers.get("user-agent") ?? "";
+      return { ...props, isMobile: /iPhone|Mobile/.test(ua), ua };
+    });
+    registerLayoutSections([key]);
+    return { key, runs: () => runs };
+  };
+
+  const load = async (key: string, ua: string) => {
+    const request = req(ua);
+    const out = await RequestContext.run(request, () =>
+      runSingleSectionLoader(makeSection(key), request),
+    );
+    return out.props as { isMobile: boolean; ua: string };
+  };
+
+  it("a mobile visitor does NOT get the variant a desktop visitor cached", async () => {
+    const { key, runs } = setupDeviceLayout();
+
+    const desktop = await load(key, DESKTOP);
+    expect(desktop.isMobile).toBe(false);
+
+    const mobile = await load(key, MOBILE);
+    // Without the axis this came back `false` — the desktop header on a phone.
+    expect(mobile.isMobile).toBe(true);
+    expect(runs()).toBe(2);
+  });
+
+  it("and the reverse: desktop after mobile", async () => {
+    const { key } = setupDeviceLayout();
+    expect((await load(key, MOBILE)).isMobile).toBe(true);
+    expect((await load(key, DESKTOP)).isMobile).toBe(false);
+  });
+
+  it("two visitors on the same device share the entry — the cache still works", async () => {
+    const { key, runs } = setupDeviceLayout();
+    await load(key, DESKTOP);
+    await load(key, DESKTOP);
+    expect(runs()).toBe(1);
+  });
+
+  it("tablet is its own entry", async () => {
+    const { key, runs } = setupDeviceLayout();
+    await load(key, MOBILE);
+    await load(key, TABLET);
+    expect(runs()).toBe(2);
+  });
+
+  it("layoutLoaderCacheKey: three devices, three keys; no request still keys", () => {
+    const keys = [MOBILE, TABLET, DESKTOP].map((ua) => layoutLoaderCacheKey("X", req(ua)));
+    expect(new Set(keys).size).toBe(3);
+    const bare = layoutLoaderCacheKey("X");
+    expect(bare).not.toContain("undefined");
+    // A request with no UA header must land on the same bucket as no request at
+    // all, so a health check does not fragment the desktop entry.
+    expect(bare).toBe(layoutLoaderCacheKey("X", new Request("https://store.com/p")));
+  });
+});

package/src/cms/sectionLoaders.ts

@@ -11,6 +11,7 @@
 
 import { RequestContext } from "@decocms/blocks/sdk/requestContext";
 import { getCacheProfile } from "../sdk/cacheHeaders";
+import { detectDevice } from "../sdk/detectDevice";
 import { djb2 } from "../sdk/djb2";
 import { withInflightTimeout } from "../sdk/inflightTimeout";
 import { withTracing } from "../sdk/observability";
@@ -212,10 +213,15 @@ export function registerSectionLoader(sectionKey: string, loader: SectionLoaderF
  *
  * Dev-only diagnostic: when a request-dependent loader (one built from
  * `withDevice`/`withMobile`/`withSearchParam`, possibly through `compose`)
- * is registered for a section that's also in `layoutSections`, the layout
- * cache will serve the first visitor's variant to every viewer for
- * `LAYOUT_CACHE_TTL` (5 min). We log a loud warning explaining the
- * remediation options. See #206.
+ * is registered for a section that's also in `layoutSections`, the layout cache
+ * may serve the first visitor's variant to every viewer for
+ * `LAYOUT_CACHE_TTL` (5 min). See #206.
+ *
+ * DEVICE is now segmented in the key ({@link layoutLoaderCacheKey}), so
+ * `withDevice`/`withMobile` are safe. The warning stays because
+ * `__requestDependent` is a single boolean and does not say WHICH signal the
+ * loader reads — a `withSearchParam` layout loader still contaminates, and we
+ * would rather warn on a safe case than stay silent on an unsafe one.
  */
 export function registerSectionLoaders(loaders: Record<string, SectionLoaderFn>): void {
   for (const [key, loader] of Object.entries(loaders)) {
@@ -228,9 +234,11 @@ export function registerSectionLoaders(loaders: Record<string, SectionLoaderFn>)
       if (requestDependent && layoutSections.has(key)) {
         console.warn(
           `[SectionLoaders] "${key}" is registered as a layout section ` +
-            `(cached for 5min by component path) but its loader is request-` +
-            `dependent (withDevice/withMobile/withSearchParam). The first ` +
-            `visitor's variant will be served to all users for 5min. Fix: ` +
+            `(cached for 5min by component path + device) but its loader is ` +
+            `request-dependent (withDevice/withMobile/withSearchParam). ` +
+            `withDevice/withMobile are safe — device is in the key. If it ` +
+            `reads a search param, cookie or geo, the first visitor's variant ` +
+            `will be served to all users for 5min. Fix: ` +
             `(1) remove "export const layout = true" from the section, ` +
             `(2) call unregisterLayoutSections(["${key}"]) in setup.ts ` +
             `after applySectionConventions, or (3) move the request-` +
@@ -267,10 +275,11 @@ const layoutInflight = new Map<string, Promise<ResolvedSection>>();
  * Layout sections (Header, Footer, etc.) are cached server-side
  * for LAYOUT_CACHE_TTL to avoid redundant enrichment on every navigation.
  *
- * The cache key is the component path only — it does NOT include UA,
- * cookies, or geo. Sections whose loader depends on those signals must
- * not be layout-cached: see {@link unregisterLayoutSections} to opt a
- * section out of the auto-discovery done by `applySectionConventions`.
+ * The cache key is the component path plus the DEVICE (see
+ * {@link layoutLoaderCacheKey}) — it does NOT include cookies, geo or search
+ * params. A section whose loader depends on THOSE must not be layout-cached:
+ * see {@link unregisterLayoutSections} to opt a section out of the
+ * auto-discovery done by `applySectionConventions`.
  */
 export function registerLayoutSections(keys: string[]): void {
   for (const key of keys) {
@@ -299,18 +308,46 @@ export function isLayoutSection(key: string): boolean {
   return layoutSections.has(key);
 }
 
-function getCachedLayout(component: string): ResolvedSection | null {
-  const entry = layoutCache.get(component);
+/**
+ * Cache key for a layout section's LOADER OUTPUT, segmented by device.
+ *
+ * This is the cache that actually carried the device leak, and it is a
+ * different one from `resolvedLayoutCache` in `cms/resolve.ts` — that one holds
+ * the CMS prop resolution, which never sees `isMobile`. `isMobile` is produced
+ * HERE, by the section's own loader (`ctx.device`, or a loader composed with
+ * `withDevice`/`withMobile`), and this cache stored it under the component path
+ * alone. Measured on a real store's PDP with Header/Footer layout-cached: the
+ * first request decided the variant for everyone — desktop first and a mobile
+ * visitor got `h-[90px]`; mobile first and a desktop visitor got
+ * `id="header-mobile-menu"`.
+ *
+ * Device is the right default axis because it is the one signal the framework
+ * itself injects into every section loader, so a layout section can depend on it
+ * without the site opting into anything. A layout whose output does not vary by
+ * device just gets up to 3 identical entries.
+ *
+ * Still NOT covered, and still the reason the `registerSectionLoaders` warning
+ * below exists: a layout loader that varies on a search param, a cookie or geo.
+ * Those are site-specific; such a section belongs outside `layoutSections`.
+ *
+ * Exported for unit testing.
+ */
+export function layoutLoaderCacheKey(component: string, request?: Request): string {
+  return `${component}::${detectDevice(request?.headers?.get?.("user-agent") ?? "")}`;
+}
+
+function getCachedLayout(cacheKey: string): ResolvedSection | null {
+  const entry = layoutCache.get(cacheKey);
   if (!entry) return null;
   if (Date.now() > entry.expiresAt) {
-    layoutCache.delete(component);
+    layoutCache.delete(cacheKey);
     return null;
   }
   return entry.section;
 }
 
-function setCachedLayout(component: string, section: ResolvedSection): void {
-  layoutCache.set(component, {
+function setCachedLayout(cacheKey: string, section: ResolvedSection): void {
+  layoutCache.set(cacheKey, {
     section,
     expiresAt: Date.now() + LAYOUT_CACHE_TTL,
   });
@@ -324,7 +361,7 @@ function resolveLayoutSection(
   loader: SectionLoaderFn,
   request: Request,
 ): Promise<ResolvedSection> {
-  const key = section.component;
+  const key = layoutLoaderCacheKey(section.component, request);
   const { index } = section;
 
   // Re-apply the caller's page-specific index onto a fresh object so the