Findings No. 44
Chromium rejects a whole batch of cookies when one of them is malformed
Chromium's cookie API rejects a whole batch if one cookie is invalid for the target, such as a __Secure- cookie without Secure on an http target. Every capture failed.
When you hand a list of cookies to a headless Chromium, one cookie it considers invalid makes it reject the whole list. A single bad entry signs the entire session out.
Replicator's thumbnail pipeline forwards the user's auth cookies into a headless browser so it can capture pages as that user. In local development every capture for a logged-in user failed with "Invalid cookie fields". The cause turned out to be the cookie names, not their values. The session cookies carried the __Secure- prefix, and Chromium refuses a __Secure- cookie unless the Secure attribute is set, which it cannot be against an http dev target. One such cookie made Chromium reject the batch. We first suspected the values, because SvelteKit's cookies.get() percent-decodes them, and switched to forwarding raw bytes; that was a sensible change but not the fix.
Production had the mirror-image bug earlier. Better Auth prefixes its cookies with __Secure- when secure cookies are on, so a lookup by the bare better-auth.session_token name found nothing, and every auth-gated capture quietly rendered the sign-in redirect.
The fix lives in buildScreenshotCookies: forward each cookie under its full stored name, drop __Secure- and __Host- cookies for non-secure targets, and drop any cookie whose value is not valid, so no single entry can fail the batch.
The general rule: filter cookies individually before handing them to a browser automation API, and check the prefix rules against the target's scheme.
Receipt: Replicator v3.190.2, v3.256.29 and v3.256.30 (collectPreviewCookies, $utils/buildScreenshotCookies.ts; FINDINGS.md, "Thumbnails, screenshots and agent browser verification").