# sqlez: Set a 5s SQLite busy timeout \(\#63923\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/e9d2934edfa5560e5efd8253aaff0d9df39a7c70)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: e9d2934edfa5560e5efd8253aaff0d9df39a7c70

Requested commit: e9d2934edfa5560e5efd8253aaff0d9df39a7c70

Commit: e9d2934edfa5560e5efd8253aaff0d9df39a7c70

Tree: 0cca935c9f7677d39f76769571e0ea31ae0cf8b2

Author: whitecat1331

Committer: GitHub

## Message

```
sqlez: Set a 5s SQLite busy timeout (#63923)

SQLite fails fast with `SQLITE_BUSY` when another process holds the
database lock. This database, and others like it, are shared between Zed
instances. SQLite allows multiple readers at once, but only one writer
at a time. Writes are short-lived, but if multiple Zed instances try to
write to the file at the same time, the default fail-fast behavior
throws `SQLITE_BUSY` and the write is dropped instead of retried. The
fix is to keep trying the write for up to five seconds, so transient
lock contention resolves and the write succeeds instead of erroring.

A concrete case is the agent threads database (`threads.db`), which
lives in the shared per-user data directory and is not namespaced by
release channel. Running two Zed instances side by side means both can
attempt to write to the same file at the same time, resulting in the
error mentioned previously.

Release Notes:

- Fixed intermittent "database is locked" errors when sharing a database
across Zed instances
```

## Parents

- [284c72404a0e8a2d3882493b8573c4817af6b52c](https://git.cafe/gitcafe/zed/commit/284c72404a0e8a2d3882493b8573c4817af6b52c?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/e9d2934edfa5560e5efd8253aaff0d9df39a7c70?format=markdown)