@emdash-cms/sandbox-workerd@0.9.7

Patch Changes

• #4668 4d4165c Thanks @khoinguyenpham04! - Fixes ctx.content.delete() in sandboxed plugins, on Cloudflare and with @emdash-cms/sandbox-workerd, so it moves entries to Trash as the admin does. Sites with an objectCache no longer keep serving the trashed entry from the cache, and the entry's updated_at and _rev no longer change.

• #4712 9e3e34d Thanks @emdash-autofix! - Raises the default sandbox subrequest allowance from 10 to 30 per invocation, allowing plugins to make more settings, storage, and HTTP bridge calls before reaching the budget. On Cloudflare, 30 bridge calls is the maximum permitted by the platform's Worker-invocation cap. The Node.js workerd runner uses the same default value but does not enforce subrequest limits.

  CPU and wall-time limits are unchanged, and existing explicit limits.subrequests overrides still apply. No configuration changes are required.

  To retain the previous ceiling, supply a custom runner module through emdash({ sandboxRunner: ... }). Its exported createSandboxRunner factory must pass limits: { subrequests: 10 } in the SandboxOptions supplied to CloudflareSandboxRunner or createSandboxRunner from @emdash-cms/cloudflare/sandbox. These are runtime-only APIs; neither sandbox() nor emdash() accepts a direct limits option. See the custom runner example.

• #4358 0008289 Thanks @emdash-autofix! - Fixes config-declared sandboxed plugins, including those running with sandbox: false, skipping plugin:install and plugin:activate on first boot. These hooks now run for plugins without a recorded state, including on the first start after upgrading, so activation hooks can set up recurring tasks without an admin disable/re-enable cycle.

  If a sandbox stops before setup finishes, plugin:install can run again on the next boot. Make install hooks safe to repeat when settings or plugin data already exist.

  createPluginRuntimeTestHost() also runs install → activate when creating a host, before test fixtures are added. A failure in the plugin's own lifecycle hook disables it in the test host, so later actions will not invoke its hooks. Tests that explicitly call actions.plugin.activate() should account for the initial activation.

  What should I do?

  Make install hooks set only missing values. If a plugin hook failed, fix the hook and re-enable the plugin from the Plugins page to run plugin:activate again.

• #4665 dbb6e09 Thanks @emdash-autofix! - Fixes sandboxed plugins failing to start when multiple EmDash sites run on the same host. Plugin listeners now use operating-system-assigned ports instead of a fixed port range, with no configuration needed. Failed starts respect restart backoff. Once the retry budget is exhausted, restart the server or install or update a plugin to retry sandboxed plugins. Startup failures report sandbox unavailability to callers while workerd's diagnostics appear in the server log.

• #4277 26528bb Thanks @emdash-autofix! - Fixes ctx.kv values disappearing when a plugin with the same ID moves between plugins: [] and sandboxed: []. This storage migration requires a coordinated upgrade; it cannot be deployed as a rolling upgrade.

  Both sandbox runners share the in-process KV store. A database migration copies existing non-settings: sandbox values and revisions without overwriting in-process values, warns about conflicting plugin IDs and keys, and retains the original sandbox rows for recovery. Uninstalling a marketplace or registry plugin with data deletion removes its shared KV values and settings; failed-install rollback preserves existing data, including partial writes made by an installation hook before it fails. Plugin-test KV fixtures and inspection use the shared store; use the settings inspection API for settings: keys.

  What should I do?

  1. Back up the database.
  2. Stop all application instances and plugin jobs that write to it.
  3. Upgrade emdash and your sandbox runner together, then build the site without starting it.
  4. Run pnpm emdash migrate against the reviewed database target.
  5. Resolve conflicting KV copies before plugins can write again.
  6. Start or deploy the upgraded site.

  Do not rely on default auto migrations for this upgrade: they start plugins immediately after migrating, leaving no conflict-review window. Mixed package versions are not automatically rejected. See the plugin upgrade guide for target selection, recovery queries, and rollback instructions. Downgrading packages alone hides post-upgrade KV writes; restoring the pre-upgrade database backup discards all site changes made since it was taken.

• Updated dependencies [c108e7b, 1eedf99, 118dcf9, 32eab5c, 40e4400, e79a7ff, 7169073, 2abe403, 22b87ed, e8ba1b8, 39a9ccb, 007f71c, b766773, ddc4e82, 638cbaf, 678a0c2, 7d48e95, 18844a7, 8418def, fbddae0, f5aab79, 5137be5, 679ad6c, 612569b, b331cf3, a17a4b3, 786fd09, 97aa98a, f8462af, 55273d7, 53b4f32, 55964d5, 235a11a, 4ccc279, ab2c40b, 98e0924, e30df1e, caca761, 7159eda, 9699645, dd4ae19, 82eb778, 73c9b70, 3f9c77b, 4d4165c, e25d2ee, 5a9f1bd, 6331f6b, 19c4f28, fc44f40, df0f952, 60fef17, b9fc5f2, dfbb9fc, 5605cec, 9aa2259, b528fc0, 752cbcd, b8886d9, c095458, 8f397e0, b436669, 4cb8305, 006cfc0, 4d4165c, 0c57c94, 56c801c, aef09ae, 1f46f0d, c9696af, 4d4165c, 9db2de8, 1357172, 2c2a1e8, 532e78b, 5845694, 284fa80, c9dffb7, 2f64c3c, 25574da, 34a8e5a, 3a13512, 1cf644e, fac4008, c54ca68, e21e01e, f298866, dafb551, 3d569ab, 6ee8a5f, d541993, 34a6816, 88a61f8, 0008289, a7cf38f, 76c1936, 222658c, c2792d5, 064b566, 96945d3, 26528bb, a107170, c77bfb1, 776c95e, 44daa08, 746db9f, 652d957]:

  • emdash@1.5.0