safeGetCanisterEnv takes the first ic_env cookie when several are present

[marc0olo]

In packages/core/src/agent/canister-env/index.ts:

return globalThis.document.cookie
  .split(";")
  .find(cookie => cookie.trim().startsWith(`${cookieName}=`));

With more than one ic_env cookie on an origin, this resolves whichever the browser happens to list first. If that one names a canister that no longer exists, every call rejects with IC0536 and the app looks like the network is down.

Why several can be present

A cookie is keyed on (name, domain, path), partitioning adds a separate jar, and cookies ignore the port. The writers of ic_env do not agree on any of those:

writer	attributes
mainnet asset canister (skills.internetcomputer.org)	Partitioned; SameSite=None; Secure; Max-Age=31536000; Path=<certified>
local gateway (icp network start)	SameSite=Lax; secure; Max-Age=31536000; Path=<certified>
typical Vite dev-server simulation	SameSite=Lax (no Path, no Max-Age)

So they accumulate rather than replace, and Max-Age=31536000 lets a stale one persist for a year. Port-insensitivity means a dev server on localhost:5173 and a gateway on localhost:8000 share a jar.

To be precise about evidence: the attributes above are measured. The duplicate-cookie failure was diagnosed against a running local network but I have not reproduced it here, so I am not claiming to know which combination produced it — only that the resolver picks arbitrarily when it happens.

Suggestion

Anything that makes the ambiguity visible or decidable, roughly in order of preference:

1. Return all candidates (or expose a getAllCanisterEnvs) so the caller can choose.
2. Prefer the non-partitioned copy, or the most specific Path — some documented rule rather than list order.
3. At minimum, console.warn when more than one ic_env is present and they disagree. That alone turns an opaque IC0536 into a one-glance diagnosis.

Related: dfinity/icp-cli#702 asks for a shorter Max-Age on the gateway-set cookie, which would reduce how long a stale copy survives but does not make the resolver deterministic.

Implementation note for whoever picks this up: cookieStore.delete silently removes nothing from the partitioned jar unless partitioned: true is passed, so any cleanup helper has to try both.

[marc0olo]

Closing in favour of dfinity/icp-cli#702, which already carries this thread — no value in splitting it across two trackers. The resolver detail is now a comment there.

[marc0olo]

Reopening and consolidating here, since the code this is about is in this repo. Closing dfinity/icp-cli#702 in favour of this issue.

Folding in the one gateway-side point from there, because it is context rather than a separate fix: the cookie is written with Max-Age=31536000 (one year) by both the mainnet asset canister and the local gateway, so a stale copy persists essentially indefinitely. A shorter lifetime would reduce exposure but would not make the resolver deterministic, which is the actual defect.

Scoping my own report honestly, as noted above: the attributes are measured and the first-match behaviour is confirmed at source, but I have not reproduced the duplicate-cookie failure myself — it was diagnosed against a running local network by someone else. So the ask is not "fix this specific reproduction", it is "make the multi-cookie case decidable instead of dependent on browser list order", plus a warning so the next person diagnoses it in a glance rather than an afternoon.

[marc0olo]

Retracting two things I stated as measured. A second reviewer re-measured and was right; my method was sloppy and I would rather correct the record than leave it.

1. The mainnet cookie has no Max-Age and no Path. A single Set-Cookie header, read on its own:

ic_env=...; Secure; SameSite=None; Partitioned

My earlier "Max-Age=31536000; Path=<certified>" was an artefact of grepping the whole response instead of the Set-Cookie line — those values came from other headers. So it is a session cookie, not a year-long one, and the "stale copy survives a year" framing I added above is wrong. Please disregard it; it was the weakest part of the case and it was not real.

2. IC0536 is method-not-found, not canister-not-found. The replica returns it with Canister has no update method and a link to #method-not-found. So the symptom I described for a dead canister id was mislabelled, and I no longer have a verified error signature for that case.

What still stands, and is still worth fixing: the resolver takes the first of several ic_env cookies, so when two are present the winner is browser list order. That is deterministic-by-accident regardless of how the duplicates arise or how long they live. A documented precedence rule, or exposing all candidates, or simply warning when two disagree, all address it.

To be explicit about the evidence now: the first-match behaviour is confirmed at source, the cookie attributes above are measured per-header, and the original duplicate-cookie failure was reported to me but never reproduced by me. Treat this as a robustness request rather than a bug report with a repro.

[marc0olo]

Scoped this out. Summary of where I landed, including two things that cut against the report as filed.

The mechanism is worse than "browser list order"

RFC 6265 §5.4 specifies the order: longer paths first, then earlier creation-times first. So getCookie isn't picking arbitrarily — among equal paths it deterministically prefers the oldest copy. That's precisely the wrong tiebreak for boot config, and it's also why the original diagnosis is more credible than "never reproduced" suggests: the spec predicts exactly the observed symptom (stale copy wins, restarting the network doesn't help).

Two corrections to the write-up

icp-cli does not write this cookie. The only Set-Cookie in dfinity/icp-cli is in an example's vite.config.ts; the gateway only proxies. So the "local gateway (icp network start)" row in the table isn't a writer.

There are two asset canister implementations and they disagree with each other:

writer	source	attributes
certified-assets (mainnet)	dfinity/certified-assets crates/canister-core/src/asset.rs:86	Secure; SameSite=None; Partitioned
dfx-era asset canister	dfinity/sdk ic-certified-assets/src/cookies.rs	SameSite=Lax
Candid UI	dfinity/candid tools/ui/src/didjs/lib.rs:219	Secure; SameSite=None; Partitioned
35 × Vite configs	dfinity/examples	SameSite=Lax;
3 × templates	icp-cli-templates hello-world/*-frontend/vite.config.ts	SameSite=Lax;

I confirmed the mainnet row against the live header on skills.internetcomputer.org — it matches the retraction above, session cookie, no Max-Age, no Path.

That gives a better origin story than the gateway theory: a frontend canister upgraded from the dfx-era asset canister to certified-assets keeps its canister id, so the old unpartitioned cookie and the new partitioned one coexist on the same host. That fits the report, and the stale copy legitimately survives a network restart because it was never the gateway's to rewrite.

How big this actually is: smaller than the table implies

Mainnet: effectively nil. One writer per origin, session-scoped, rewritten on every HTML response. Nothing accumulates.

Local: narrower than it looks. Local frontends are served at http://<frontend-canister-id>.localhost:8000/ and none of these writers set Domain, so every ic_env is host-only. abc.localhost and localhost:5173 do not share a jar — the dev-server/asset-canister collision the table implies doesn't happen. Recreating a network yields a new canister id and therefore a new jar too.

So the realistic window is the asset-canister implementation swap above, plus a contrived sub-route/Path case I couldn't turn into a plausible failure.

Plan

Doing: #1386 — collect every ic_env cookie, stay silent when the copies agree, throw a named ConflictingCanisterEnvErrorCode when they don't. ~15 lines, no bundle cost. It justifies itself on diagnosis cost regardless of how rare the trigger is, and it's the only change that reaches canisters and projects already deployed, since every writer change is upgrade-gated.

Rejecting suggestion 2 (prefer non-partitioned, or most specific Path). Not implementable: document.cookie exposes only name=value, so the attributes to sort on don't exist at the read site, and cookieStore.getAll() is Chromium-only. It's also backwards — the authoritative mainnet writer is the partitioned one, so the rule would prefer a stray dev-server cookie over the real one.

Deferring suggestion 1 (getAllCanisterEnvs). Reasonable escape hatch, but it hands an unresolvable ambiguity to every app author. Happy to add it if someone hits a case where the throw is wrong.

Not doing the writer sweep — no changes to certified-assets, candid, sdk, or the 38 dev-server configs. Path=/ everywhere is correct hygiene, but with host isolation I can't construct a realistic failure it prevents, and set-cookie is a certified response header on the asset canister, so it isn't a free edit. Worth folding in opportunistically when those files are touched anyway.

One adjacent problem worth separating

Two local projects on localhost:5173 and localhost:5174 are the same host, because cookies ignore port. Both dev-server templates write ic_env with no Domain and no Path, so the second doesn't duplicate the first — it replaces it, and project A's tab reads project B's canister ids. No cookie attribute fixes that (partitioning keys on site, and both are localhost), and the change here wouldn't fire either, since there's only ever one cookie and it's simply wrong. That's a template problem — dev servers should inject the env via Vite define rather than a cookie. Filed separately; I haven't reproduced it, it follows from the template plus cookie scoping.