Interface InitOptions

The deployment execution fence (do-runner/execution-fence.ts).

OPTIONAL only for a { DB } source, where init builds one from that same binding — the fence must live in the database it fences, and init is the one place that holds both. Passing a store here overrides the auto-build (a host sharing one instance across its Durable Objects). There is deliberately NO 'none' on this branch: a host that hands init a database cannot end up with a fence-less runtime, whatever it forgets or opts out of, which is the fail-closed-by-construction half of the contract.

REQUIRED, and widened to include the opt-out, for a { storage } source — see ExecutionFenceWiring, which spells out why every fence option that CAN be required is.

Storage instance id when init builds the D1 store. Default: 'flowsafe'.

The host Durable Object's single pubsub identity — createHostPubSub() for the default in-process emitter, or any PubSub the host built. init() is where a DO's identity is established: it echoes the instance on InitResult, so every consumer in the isolate takes THAT one rather than building its own (core defaults a fresh emitter per createRun, and two such feeds never see each other's events — see pubsub.ts).

OPT-IN: absent, InitResult.pubsub is undefined and no consumer has one to pass, so the host is byte-identical to before this seam existed (polling stays the fallback).

Server-side requestContext source consulted on every start/resume — the grant-minting seam. See RequestContextProvider in runtime.ts.

The deployment's start reservations, for a { storage } source only.

A { DB } source ignores this and always gets the store built from its own binding — the reservation table must live in the database the runs live in, and init is the one place that holds both.

OPTIONAL on THIS branch only, where it is ignored. StorageInitOptions requires it, and widens it to include the opt-out — see there for why a { storage } host must write the answer down.

Table name prefix when init builds the D1 store.