Sandboxed plugins on Cloudflare are D1-only

[ascorbic]

Discovered while resolving #1622 (event-scoped DB connections for connection-backed adapters).

Problem

Sandboxed plugins on the production Cloudflare runner talk to the database through the PluginBridge Durable Object (packages/cloudflare/src/sandbox/bridge.ts). That bridge is hardcoded to D1:

const db = new Kysely<unknown>({ dialect: new D1Dialect({ database: this.env.DB }) });
// ...and many this.env.DB.prepare(...) calls

It constructs its own D1 connection from env.DB, completely independent of the adapter the site configured (d1(), hyperdrive(), durableObjects(), ...). Consequences:

• On a hyperdrive() deployment there may be no env.DB binding at all, so sandboxed plugins that read/write content, media, or plugin storage fail or hit the wrong database.
• Even where a D1 binding coexists, sandboxed plugins would read/write a different database than the rest of the site.

So sandboxed plugins are effectively D1-only. This is a pre-existing constraint, independent of the connection-scoping work in #1622 (which covered cron, plugin hook contexts, and media providers in core).

Why #1622 did not fix this

#1622 threaded an event-scoped DB resolver through core subsystems (cron executor, plugin context factory, media providers). The sandbox bridge does not use the runtime db at all; it stands up its own D1 connection inside the DO, so there was nothing for the resolver to flow into. Fixing it requires teaching the bridge to use the configured adapter.

Proposed direction

• Give the PluginBridge DO access to the configured adapter rather than a hardcoded D1Dialect. For connection-backed adapters (Hyperdrive/pg) the DO must open its own event-scoped connection inside each bridge request (the same cross-event constraint as feat(cloudflare): Hyperdrive Postgres database adapter #1614/Thread an event-scoped DB connection through cron, plugin contexts, media providers, and sandbox runner #1622), not reuse a singleton.
• Route bridge storage/content/media operations through the same repositories core uses, against the resolved connection, so sandboxed and non-sandboxed plugins see one database.
• Decide the dev/workerd runner story (packages/workerd/src/sandbox/runner.ts uses options.db directly; fine on Node, but should stay consistent).

Acceptance

• Sandboxed plugins read/write the same database as the rest of the site on d1(), hyperdrive(), and DO SQL adapters.
• No cross-event connection reuse in the bridge on connection-backed adapters.
• Remove the "sandboxed plugins are D1-only" note from the hyperdrive() JSDoc and adapter module header.

[ascorbic]

@emdashbot repro

[ascorbic]

@emdashbot repro

[emdashbot]

On it. I'll investigate and report back; this usually takes a few minutes.

[emdashbot]

On it. I'll investigate and report back; this usually takes a few minutes.

[emdashbot]

On it. I'll investigate and report back; this usually takes a few minutes.