Add deleteAllDurableObjects() to workerd:unsafe

[penalosa]

Adds a deleteAllDurableObjects() method to the workerd:unsafe module. This aborts all Durable Objects, deletes all their underlying storage (SQLite files on disk), and cancels all scheduled alarms. After calling this, DOs can be recreated with clean state.

Changes

• workerd:unsafe module — new deleteAllDurableObjects() JS method
• IoChannelFactory — new deleteAllActors() virtual, mirroring abortAllActors()
• AlarmScheduler — new deleteAll() that cancels all in-memory alarm tasks and wipes the DB (DELETE FROM _cf_ALARM); called per-namespace since PR Store Durable Object alarms per-namespace on disk #6104 moved alarms to per-namespace schedulers
• Server — new deleteAllActors() that iterates evictable namespaces, calling ActorNamespace::deleteAll() which: aborts running actors, calls AlarmScheduler::deleteAll(), then deletes all actor SQLite files from disk
• Tests — verifies storage is gone after delete, alarms don't fire, preventEviction namespaces are unaffected

[ask-bonk]

I'm Bonk, and I've done a quick review of your PR.

Adds deleteAllDurableObjects() to workerd:unsafe that aborts all evictable DOs, wipes their on-disk SQLite storage, and cancels alarms.

1. [LOW] Code duplication between Server::deleteAllActors and Server::abortAllActors — The two methods share identical evictable-namespace iteration logic (~15 lines). If that logic ever changes (e.g. a new ActorConfig variant), both must be updated in lockstep. Consider factoring out the iteration into a shared helper that accepts a per-namespace callback, or having deleteAllActors delegate to abortAllActors and then do a second pass for storage cleanup only.

This review was generated by an AI code reviewer and may contain errors. Please verify any suggestions before applying them.

[ask-bonk]

I'm Bonk, and I've done a quick review of your PR.

The PR adds deleteAllDurableObjects() to workerd:unsafe that aborts all evictable DOs, wipes their on-disk SQLite storage, and cancels alarms. The implementation is correct and well-tested.

I posted one LOW severity comment about code duplication between Server::deleteAllActors and Server::abortAllActors — they share ~15 lines of identical evictable-namespace iteration logic. The suggestion is to have deleteAllActors delegate to abortAllActors for the abort+alarm portion and then do a second pass for storage file cleanup only, reducing the maintenance burden if the iteration logic ever changes.

github run

[kentonv]

Can you please wait until #6104 is landed and then re-prompt this?

I don't want to delay #6104 any more.

[codspeed-hq]

Merging this PR will not alter performance

✅ 70 untouched benchmarks
⏩ 129 skipped benchmarks¹

---

_{Comparing penalosa/delete-all-durable-objects (016ddd6) with main (32a5758)}

Footnotes

1. 129 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[penalosa]

/bonk fix the conflicts in this PR

[ask-bonk]

Re-review after #6104 has landed (per kentonv's request to wait).

• [HIGH] Merge conflicts — The PR's mergeable state is dirty now that #6104 has landed. A rebase is needed before this can merge. The alarm scheduler changes in #6104 (per-namespace alarms, AlarmScheduler constructor changes) likely conflict with Server::deleteAllActors and possibly the abortAllActors call site.
• [MEDIUM] Code duplication (still present) — Server::deleteAllActors and Server::abortAllActors still share ~15 lines of identical evictable-namespace iteration logic, as flagged in my prior review. Since ActorNamespace::deleteAll already delegates to abortAll internally, Server::deleteAllActors could skip the per-namespace abort and just call abortAllActors(reason) first, then do a second pass for storage cleanup only. This would also mean the deleteAllAlarms() call wouldn't need to be duplicated — it's already done in abortAllActors. Worth considering during the rebase.
• [LOW] Post-rebase consideration: per-namespace alarm deletion — With #6104's per-namespace alarm storage, you may want deleteAllActors to only delete alarms for evictable namespaces (matching the storage-deletion scope) rather than unconditionally calling deleteAllAlarms() on the global scheduler. Currently both abortAllActors and deleteAllActors wipe all alarms globally, which also affects preventEviction namespaces' alarms. This may be intentional, but worth verifying against #6104's new namespace-aware alarm model.

The implementation logic itself (abort actors → release file handles → delete storage files) is sound. The test coverage is good — verifies storage deletion, alarm cancellation, and preventEviction exclusion.

This review was generated by an AI code reviewer and may contain errors. Please verify any suggestions before applying them.

[ask-bonk]

Review posted on PR #6357. Here's a summary of the findings:

HIGH — Merge conflicts: The PR is now in dirty mergeable state after #6104 ("Store Durable Object alarms per-namespace on disk") merged. A rebase is needed.

MEDIUM — Code duplication: Server::deleteAllActors and Server::abortAllActors share ~15 lines of identical evictable-namespace iteration logic. Since ActorNamespace::deleteAll() already delegates to abortAll() internally, the Server::deleteAllActors method could call abortAllActors(reason) first, then do a second pass for storage cleanup only. This eliminates the duplication and makes the rebase easier.

LOW — Per-namespace alarm deletion: With #6104's per-namespace alarm model, it may be worth verifying whether deleteAllAlarms() should only target evictable namespaces' alarms rather than wiping all alarms globally (which also affects preventEviction namespaces).

The implementation logic (abort → release handles → delete storage) is sound, and test coverage is good.

github run

[penalosa]

@kentonv this should be ready for review now—I've recreated on top of main

[kentonv]

I want to note that this is sort of scary functionality to have. I would be extremely upset if, say, wrangler dev were to ever just delete all my local DO data. I'm guessing that's not the intended use, but please be very careful with how you use this.

[penalosa]

I want to note that this is sort of scary functionality to have. I would be extremely upset if, say, wrangler dev were to ever just delete all my local DO data. I'm guessing that's not the intended use, but please be very careful with how you use this.

To clarify the intended use case here, this is specifically to support a user facing API in @cloudflare/vitest-pool-workers to allow people to clear populated test data. It won't be used in Wrangler or Miniflare, and won't be called automatically in Vitest—a user will have to import an API from cloudflare:test and call it themselves. In the testing use case this is a lot less dangerous, as most data is expected to be ephemeral and re-createable.

[penalosa]

/bonk

[ask-bonk]

Re-review after the rebase onto main and commit 9e4aed0 addressing kentonv's metadata.sqlite concern.

• [MEDIUM] Code duplication at Server::deleteAllActors / Server::abortAllActors — Still present from prior reviews. The two methods share identical evictable-namespace iteration logic (~15 lines). Since ActorNamespace::deleteAll() already calls abortAll() internally, Server::deleteAllActors could call abortAllActors(reason) first and then do a storage-only cleanup pass. This would mean changes to the iteration logic only need to happen in one place. Noted inline — feel free to keep the current factoring if you prefer the explicitness.
• kentonv's concern addressed — Commit 9e4aed0 correctly skips metadata.sqlite* files during storage deletion and instead wipes alarm rows via AlarmScheduler::deleteAll(). The startsWith("metadata.sqlite") check covers WAL/journal companions. The ordering (abort actors → clear alarms → delete files) is sound.
• Alarm scheduler deleteAll() is safe — alarms.clear() cancels in-flight alarm promises before the DB wipe. Since actors are already aborted at this point, any STARTED alarm tasks would already be broken. Prepared statements survive the DELETE FROM since the table isn't dropped.
• Test coverage is good — Tests verify storage wipe, alarm cancellation, and preventEviction exclusion. The switch from inMemory to localDisk storage correctly exercises on-disk file deletion.

This review was generated by an AI code reviewer and may contain errors. Please verify any suggestions before applying them.

[ask-bonk]

Review posted on PR #6357. Here's a summary:

Overall: The implementation is sound. The abort → alarm wipe → file deletion ordering is correct, and the fix for kentonv's metadata.sqlite concern (commit 9e4aed0) properly skips the alarm DB file and its WAL/journal companions while clearing rows via DELETE FROM.

Findings posted:

1. [MEDIUM] Code duplication at Server::deleteAllActors / Server::abortAllActors — both share ~15 lines of identical evictable-namespace iteration. Since ActorNamespace::deleteAll() already delegates to abortAll(), the Server:: method could call abortAllActors() first then do a storage-only pass. Low risk, matter of preference.

2. No safety issues found — AlarmScheduler::deleteAll() correctly clears in-memory alarm promises (cancelling them) before wiping DB rows. Prepared statements survive the DELETE FROM since the table isn't dropped. The const qualification chain through IoChannelFactory → Server → ActorNamespace is consistent. Repeated calls are safe (idempotent on empty state).

3. Test coverage is good — verifies storage wipe, alarm cancellation after delete, and preventEviction exclusion.

Reviews:

• Summary review
• Inline comment on code duplication

github run

[github-actions]

The generated output of @cloudflare/workers-types matches the snapshot in types/generated-snapshot 🎉