[PR #23708] [CLOSED] fix(db): default DATABASE_ENABLE_SQLITE_WAL to True so async+sync engines stop deadlocking on file lock #42957

New Issue

GiteaMirror · 2026-04-25T14:42:46-05:00

GiteaMirror commented

2026-04-25 14:42:46 -05:00

📋 Pull Request Information

Original PR: https://github.com/open-webui/open-webui/pull/23708
Author: @Classic298
Created: 4/14/2026
Status: ❌ Closed

Base: dev ← Head: claude/fix/sqlite-wal-default

📝 Commits (4)

d863da5 fix(db): default DATABASE_ENABLE_SQLITE_WAL to True so async+sync engines stop deadlocking on file lock
20b6e78 fix(db): explicitly set journal_mode=DELETE in SQLCipher creator when WAL is opted out
1d8744f fix(db): verify SQLite journal_mode actually applied; correct SQLCipher comment
950922f fix(db): make _set_sqlite_journal_mode non-failing and tailor mismatch warnings

📊 Changes

2 files changed (+109 additions, -14 deletions)

View changed files

📝 backend/open_webui/env.py (+9 -1)
📝 backend/open_webui/internal/db.py (+100 -13)

📄 Description

Open WebUI runs both a sync engine (sqlite3 / sqlcipher3 — used at startup, by Alembic, the peewee migration shim, healthchecks, and a couple of legacy paths) and an async engine (aiosqlite) against the same SQLite database file. SQLite's default rollback-journal mode takes an exclusive lock on the entire DB file for every writer, which means the moment one engine writes, every other reader/writer across both engines blocks on the same file lock. Under a normal request mix this surfaces as the entire FastAPI loop stalling whenever a long write (e.g. file-upload metadata + chat persistence + embedding status updates) happens to overlap.

WAL mode lets readers proceed while a writer is committing and is required for the dual-engine layout to behave; rollback-journal is only safe for single-process, single-engine use which Open WebUI is not.

Flip the default of DATABASE_ENABLE_SQLITE_WAL from False to True. Operators who genuinely need rollback-journal can still set DATABASE_ENABLE_SQLITE_WAL=False explicitly. Also apply the same journal-mode policy in the SQLCipher connection creator so encrypted deployments get the same fix.

Contributor License Agreement

By submitting this pull request, I confirm that I have read and fully agree to the Contributor License Agreement (CLA), and I am providing my contributions under its terms.

Note

Deleting the CLA section will lead to immediate closure of your PR and it will not be merged in.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/open-webui/pull/23708 **Author:** [@Classic298](https://github.com/Classic298) **Created:** 4/14/2026 **Status:** ❌ Closed **Base:** `dev` ← **Head:** `claude/fix/sqlite-wal-default` --- ### 📝 Commits (4) - [`d863da5`](https://github.com/open-webui/open-webui/commit/d863da545b2f63ea30cc0f888fb189187cdff76e) fix(db): default DATABASE_ENABLE_SQLITE_WAL to True so async+sync engines stop deadlocking on file lock - [`20b6e78`](https://github.com/open-webui/open-webui/commit/20b6e7808fb9331e29a0a552d854303683cbc953) fix(db): explicitly set journal_mode=DELETE in SQLCipher creator when WAL is opted out - [`1d8744f`](https://github.com/open-webui/open-webui/commit/1d8744f99a95fccc6c5dfbdce44f7abdaa71b8c6) fix(db): verify SQLite journal_mode actually applied; correct SQLCipher comment - [`950922f`](https://github.com/open-webui/open-webui/commit/950922f8694f93c6902fc3a313b89cab8bc78665) fix(db): make _set_sqlite_journal_mode non-failing and tailor mismatch warnings ### 📊 Changes **2 files changed** (+109 additions, -14 deletions) <details> <summary>View changed files</summary> 📝 `backend/open_webui/env.py` (+9 -1) 📝 `backend/open_webui/internal/db.py` (+100 -13) </details> ### 📄 Description Open WebUI runs both a sync engine (sqlite3 / sqlcipher3 — used at startup, by Alembic, the peewee migration shim, healthchecks, and a couple of legacy paths) and an async engine (aiosqlite) against the same SQLite database file. SQLite's default rollback-journal mode takes an exclusive lock on the entire DB file for every writer, which means the moment one engine writes, every other reader/writer across both engines blocks on the same file lock. Under a normal request mix this surfaces as the entire FastAPI loop stalling whenever a long write (e.g. file-upload metadata + chat persistence + embedding status updates) happens to overlap. WAL mode lets readers proceed while a writer is committing and is required for the dual-engine layout to behave; rollback-journal is only safe for single-process, single-engine use which Open WebUI is not. Flip the default of `DATABASE_ENABLE_SQLITE_WAL` from `False` to `True`. Operators who genuinely need rollback-journal can still set `DATABASE_ENABLE_SQLITE_WAL=False` explicitly. Also apply the same journal-mode policy in the SQLCipher connection creator so encrypted deployments get the same fix. ### Contributor License Agreement  - [X] By submitting this pull request, I confirm that I have read and fully agree to the [Contributor License Agreement (CLA)](https://github.com/open-webui/open-webui/blob/main/CONTRIBUTOR_LICENSE_AGREEMENT), and I am providing my contributions under its terms. > [!NOTE] > Deleting the CLA section will lead to immediate closure of your PR and it will not be merged in. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2026-04-25 14:42:46 -05:00

GiteaMirror closed this issue

2026-04-25 14:42:48 -05:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#42957