Follow-up from the portable-encryptedSupabase design (#708).
Why this exists
The portable-runtime series ships an export map that routes workerd to the WASM build, and it claims Cloudflare Workers as a target. No workerd process ever loads the bundle. The whole of the Workers evidence is:
- one
import.meta.resolve under Node with --conditions=workerd, and
- a property test asserting the export map against a hand-rolled ten-line reimplementation of Node's resolution algorithm — a model of the resolver, not a resolver. A divergence between that model and Node / esbuild / webpack passes silently.
Supabase Edge Functions, by contrast, are covered by a real Deno run of the emitted dist/index.wasm.js with no --allow-ffi, in CI. That asymmetry is why the Workers claim shipped qualified.
Current wording — do not change it without this test
Every shipping artifact — skills/stash-supabase/SKILL.md, the README, the changeset, AGENTS.md — says:
Cloudflare Workers: the build and export conditions target it, validated by export-map resolution rather than by a Worker runtime test.
A bare "runs in Cloudflare Workers" is deliberately absent everywhere.
What to build
A wrangler dev-driven smoke test that loads @cipherstash/stack-supabase in a real Worker isolate and exercises encryptedSupabase(supabaseClient, { schemas }) in declared mode. Credential-free is enough to start — proving the import graph resolves and the WASM blob instantiates under workerd is the part no existing test covers.
Two things worth asserting while you are there:
- Bundle size. The inlined blob (
@cipherstash/protect-ffi/dist/wasm/protect_ffi_inline.js) is 4,379,681 bytes raw / 1,564,507 gzipped. Cloudflare's limit applies compressed — 3 MB free, 10 MB paid — so this consumes roughly half a free Worker's entire budget before any application code.
nodejs_compat and compatibility_date >= 2024-09-23, which is what the pg path would need if a Worker ever introspects. The package's pg peer floor was raised to >=8.16.3 for exactly this.
Definition of done
Delete the qualification from the skill, README and AGENTS.md in the same PR that lands the test.
Follow-up from the portable-
encryptedSupabasedesign (#708).Why this exists
The portable-runtime series ships an export map that routes
workerdto the WASM build, and it claims Cloudflare Workers as a target. No workerd process ever loads the bundle. The whole of the Workers evidence is:import.meta.resolveunder Node with--conditions=workerd, andSupabase Edge Functions, by contrast, are covered by a real Deno run of the emitted
dist/index.wasm.jswith no--allow-ffi, in CI. That asymmetry is why the Workers claim shipped qualified.Current wording — do not change it without this test
Every shipping artifact —
skills/stash-supabase/SKILL.md, the README, the changeset,AGENTS.md— says:A bare "runs in Cloudflare Workers" is deliberately absent everywhere.
What to build
A
wrangler dev-driven smoke test that loads@cipherstash/stack-supabasein a real Worker isolate and exercisesencryptedSupabase(supabaseClient, { schemas })in declared mode. Credential-free is enough to start — proving the import graph resolves and the WASM blob instantiates under workerd is the part no existing test covers.Two things worth asserting while you are there:
@cipherstash/protect-ffi/dist/wasm/protect_ffi_inline.js) is 4,379,681 bytes raw / 1,564,507 gzipped. Cloudflare's limit applies compressed — 3 MB free, 10 MB paid — so this consumes roughly half a free Worker's entire budget before any application code.nodejs_compatandcompatibility_date>= 2024-09-23, which is what thepgpath would need if a Worker ever introspects. The package'spgpeer floor was raised to>=8.16.3for exactly this.Definition of done
Delete the qualification from the skill, README and
AGENTS.mdin the same PR that lands the test.