VARAR_UPDATE never reaches oaths that run in a sandboxed runner, so drift cannot be accepted at all

[aslakhellesoy]

VARAR_UPDATE=1 is read inside the process that executes the oaths (@varar/vitest/dist/runtime.js, via process.env). When that process is a sandbox rather than the Node process the user typed the command in, the variable never arrives and accepting drift is impossible — with no indication of why.

Where I hit it

A SvelteKit/Cloudflare Workers project. The varar oaths run under @cloudflare/vitest-pool-workers, i.e. inside workerd, which sees only the bindings its miniflare config gives it — not the shell environment.

VARAR_UPDATE=1 pnpm vitest run --project varar
# ... same drift failure, unchanged, every time

I had legitimate drift to accept (setup moved into a referenced section, #117). There was no way to accept it. I re-ran it several times assuming I'd mistyped something, then went reading runtime.js to find out why it was being ignored.

The fix at my end was to pass it through as a binding:

const vararProjectMiniflare = {
  bindings: { MIGRATIONS: migrations, VARAR_UPDATE: process.env.VARAR_UPDATE ?? '' },
}

Which works, but nobody is going to guess it.

Why I think this is yours rather than mine

@varar/vitest's reporter already reads VARAR_UPDATE on the Node side — that's where pruneBaselines runs (#70). So the flag is half-handled in a process that can definitely see it, and half-handled in one that may not. The split is invisible until it bites.

Worth noting this isn't Cloudflare-specific: any sandboxed or remote runner has the same shape — browser-based runners, and I'd guess vitest --browser too.

Suggestions

1. Reconcile baselines in the reporter, not the runtime. The reporter already owns lock-file pruning and already reads the flag. If it also owned per-oath baseline reconciliation, VARAR_UPDATE would be read exactly once, in a process guaranteed to see it, and this whole class of problem disappears. This is my preference by some distance.
2. Have the vitest plugin forward it. varar() could inject VARAR_UPDATE into the test environment so pool authors don't have to know. Narrower fix, but it makes the common case work.
3. At minimum, say so. If the runtime can't see the flag, it can't know it was set — but the reporter can. When the reporter sees VARAR_UPDATE and the run still reports unaccepted drift, that is a contradiction it can detect and explain: "VARAR_UPDATE was set but the oath runtime did not see it — your test runner may sandbox the environment." That single line would have saved me the source-reading trip.