fix(vtex): merge headers Headers-aware so init.headers Cookie survives

[vibe-dex]

Summary

Closes a latent failure mode in the framework's outbound header merging that any forwarder relying on browser-supplied cookies can trigger.

The bug

When a caller builds init.headers as a Headers instance (as createVtexCheckoutProxy does since 1.15.0 — routing through getVtexFetch() for tracing), the framework's per-call header merge silently dropped the caller's cookies:

headers: {
  ...authHeaders(),
  ...(segmentCookie ? { cookie: segmentCookie } : {}),
  ...init?.headers,   // ← `new Headers({...})` spreads to `{}`
}

A Headers instance has no own enumerable entries, so the spread collapses to {} — wiping every header the caller set on the Headers object, cookies included. The downstream service receives an effectively cookieless request even though the proxy was forwarding a fully-populated browser request.

Changes

• vtex/client.ts — introduce mergeHeaders(auth, segmentCookie, callerHeaders), backed by the Headers constructor, which absorbs every HeadersInit shape (Headers, string[][], Record) correctly. Use it from vtexFetchResponse and vtexCachedFetch.
• vtex/client.ts — hoist vtex_segment cookie injection into vtexCachedFetch and intelligentSearch. Closes the gap that previously forced consumers to wrap setVtexFetch with their own (often Headers-unsafe) injectors. "Caller wins" precedence preserved via hasCookieHeader.
• vtex/__tests__/client-segment-cookie.test.ts — regression test for the Headers-init path (the exact shape createVtexCheckoutProxy passes), plus full describe blocks for the new vtexCachedFetch and intelligentSearch injection paths. 12 tests covering this surface; 418/418 in the full suite.

Test plan

• npm test — 33 files, 418/418 pass
• npx tsc --noEmit — clean

Risk

Low. The refactor strictly widens what init.headers shapes are tolerated; the new helper returns a Headers instance instead of a plain object, but both Workers and Node accept either as HeadersInit. The two new injection sites (vtexCachedFetch, intelligentSearch) are gated on "caller didn't supply a cookie", so they're no-ops for any callsite that already passes one explicitly.

[cubic-dev-ai]

1 issue found across 3 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="vtex/client.ts">

<violation number="1" location="vtex/client.ts:321">
P1: `vtexCachedFetch` now varies upstream responses by segment cookie, but cache keys still ignore that cookie. This can serve another region's cached response for the same URL.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: vtexCachedFetch now varies upstream responses by segment cookie, but cache keys still ignore that cookie. This can serve another region's cached response for the same URL.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At vtex/client.ts, line 321:

<comment>`vtexCachedFetch` now varies upstream responses by segment cookie, but cache keys still ignore that cookie. This can serve another region's cached response for the same URL.</comment>

<file context>
@@ -282,12 +309,23 @@ export async function vtexCachedFetch<T>(
+	// unsafe and clobbered the proxy's full Cookie header). Inline here
+	// keeps the surface small; if a third callsite appears we extract a
+	// shared helper.
+	const segmentCookie = !hasCookieHeader(init?.headers) ? getSegmentCookieHeader() : null;
+
 	return fetchWithCache<T>(
</file context>