SQLite-backed workflow storage hits PersistenceError / database is locked under concurrent runner + client access

[schickling]

I hit what looks like a SQLite concurrency problem when using @effect/workflow with @effect/cluster SQL storage.

The setup is intentionally minimal:

• one long-lived process starts a workflow runner against a SQLite database
• separate client processes connect to the same SQLite-backed workflow store
• those clients repeatedly poll the workflow and send a cancellation signal

Reproduction

https://github.com/schickling-repros/2026-04-effect-workflow-sqlite-locking

npm install
npm run repro

Expected

Concurrent workflow control-plane access against the same SQLite store should not emit storage-read warnings or persistence failures.

Actual

The repro emits warnings like:

• Could not read messages from storage
• PersistenceError
• SqliteError: database is locked

The script exits non-zero after it detects the locking warning.

Versions

• @effect/workflow: 0.18.0
• @effect/cluster: 0.58.0
• @effect/sql-sqlite-node: 0.52.0
• effect: 3.21.0
• Node.js: v24.14.0
• OS: Darwin 25.2.0 arm64

One thing that stood out while testing: separate-process control access is exactly where this becomes visible. A single process can appear fine, but once one process owns the runner and another process polls/signals through the same SQLite store, the locking warnings show up quickly.

If you want, I can also try a Postgres-backed variant of the same repro to confirm whether this is specifically a SQLite storage limitation rather than a broader workflow-engine issue.

---

_{Filed by an AI assistant on behalf of @schickling}