All of the important changes are in
[`db.rs`](https://github.com/zed-industries/zed/pull/51809/changes#diff-2f644eab943bfa58feec29256281a3d9e8d4d7784cd34783e845af8beb15b16d).
Consider reading the commit log in order to review this work.
The DB crate's macro and API was changed to fix flakiness observed in
the MultiWorkspace tests when run locally. This flakiness was caused by
a shared `static LazyLock`, that caused concurrent test runs to interact
with the same underlying in-memory database. This flakiness wasn't
possible on CI due to it's usage of `cargo nextest`, whose
process-per-test approach masked this problem.
Essentially, I've changed the `static_connection` macro to remove the
static database variable and redone the internal model. Now, all
database types are thin wrappers around a generic `AppDatabase`. The
`AppDatabase` collects all of the individual table's migrations via the
`inventory` crate, and so only runs the migrations once on startup,
rather than a dozen times on startup.
The new API requires a `cx` so that we can replace the database returned
at runtime, rather than relying exclusively on a process-global
thread-local. However, we are still using a `static LazyLock` so that we
only need to take an `&App`, instead of an `&mut App`. These databases
types are `Clone + Send + Sync`, so you can easily capture-and-move the
database into background tasks and other places that don't have a `cx`.
For tests that require database isolation, it is now possible to set
their own database in init. See
[`workspace::init_test`](https://github.com/zed-industries/zed/pull/51809/changes#diff-041673bbd1947a35d45945636c0055429dfc8b5985faf93f8a8a960c9ad31e28R13610),
for the flakiness fix.
Best part, this change should be entirely compiler driven, so the Zed
agent was able to make the app-wide refactor easily.
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
## Summary
Extends #46011 to make folds survive tab close and workspace cleanup.
- Adds `file_folds` table keyed by `(workspace_id, path)` instead of
`editor_id`
- Follows the `breakpoints` table pattern in
`workspace/src/persistence.rs`
- Includes backwards-compatible migration from `editor_folds` on first
read
cc @Veykril - you reviewed the original fold persistence PR, this
extends it to handle the tab-close case.
## Problem
Folds stored by `editor_id` get deleted when:
1. User closes a tab
2. Tab is removed from workspace serialization
3. On next Zed start, `cleanup()` deletes editor rows not in
`loaded_items`
4. `ON DELETE CASCADE` wipes associated folds
5. User manually reopens file → folds gone
This is especially painful for PKM/notes workflows where folds represent
permanent document structure (collapsed sections, reference blocks,
etc).
## Solution
Store folds by file path, not editor ID. The `breakpoints` table already
proves this pattern works in Zed - breakpoints persist across tab close
because they're keyed by path.
## Migration
The PR includes backwards-compatible migration: reads from `file_folds`
first, falls back to `get_editor_folds()`, and migrates old data on
first read. Happy to remove this if you'd prefer a clean break - I'd
delete `get_editor_folds()`, remove the fallback logic in
`read_metadata_from_db()`, and add a `DROP TABLE IF EXISTS editor_folds`
migration. Users would lose any folds saved before the update.
## Test Plan
- [x] Unit test for `file_folds` queries in `persistence.rs`
- [x] Manual test: Open file → fold → close tab → quit Zed → reopen →
manually open file → folds restored
Release Notes:
- N/A
Co-authored-by: Hector <hector@cyberneticwilderness.com>
## Summary
Fixes#33633 - folds corrupting after external file modifications.
The existing fold persistence stored raw byte offsets, which become
stale when files are modified externally (git operations, other editors,
sync tools). This caused folds to capture wrong content on restore -
users reported "wrong lines getting folded" with systematic offsets.
**Solution: Content fingerprinting**
- Store 32-byte content samples at fold boundaries
- On restore, validate fingerprints match; if not, search buffer for new
positions
- Handles edge cases: short folds (< 32 bytes), duplicate content,
boundary positioning
**Bonus fix: Ungraceful exit survival**
- Entity IDs change between sessions, but workspace cleanup's CASCADE
DELETE was wiping folds before new editors could save
- Now migrates folds to new entity_id immediately after restore
## Test plan
- [x] Unit test for fingerprint storage/retrieval
(`test_save_and_get_editor_folds_with_fingerprints`)
- [x] Manual test: fold sections, add content at file start externally,
reopen → folds restore at correct positions
- [x] Manual test: fold sections, Ctrl+C, reopen → folds survive
- [x] Existing fold tests pass (`cargo test -p editor`)
## Release Notes
- N/A
---------
Co-authored-by: Hector <hector@cyberneticwilderness.com>
Closes#5355
Release Notes:
- Fixed rendering glitches with files with more than 16 million lines
(that occured due to floating number rounding errors).
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Part of https://github.com/zed-industries/zed/issues/16472
* Adds debug logging to everywhere near INSERT/UPDATEs in the DB
So something like
`env RUST_LOG=debug,wasmtime_cranelift=off,cranelift_codegen=off,vte=off
cargo run` could be used to view these (current zlog seems to process
the exclusions odd, so not sure this is the optimal RUST_LOG line) can
be used to debug any further writes.
* Removes excessive window stack serialization
Previously, it serialized unconditionally every 100ms.
Now, only if the stack had changed, which is now check every 500ms.
* Removes excessive terminal serialization
Previously, it serialized its `cwd` on every `ItemEvent::UpdateTab`
which was caused by e.g. any character output.
Now, only if the `cwd` has changed at the next event processing time.
Release Notes:
- Fixed more excessive DB writes
See ["mtime comparison considered
harmful"](https://apenwarr.ca/log/20181113) for details of why
comparators other than equality/inequality should not be used with
mtime.
Release Notes:
- N/A
Certain files like Rust stdlib ones can be opened by cmd-clicking on
terminal, editor contents, etc.
Those files will not belong to the current worktree, so a fake worktree,
with a single file, invisible (i.e. its dir(s) will not be shown in the
UI such as project panel), will be created on the file opening.
When the file is closed, the worktree is closed and removed along the
way, so those worktrees are considered ephemeral and their ids are not
stored in the database.
This causes issues on reopening such files when they are closed.
The PR makes Zed to fall back to opening the file by abs path when it's
not in the project metadata, but has the abs path stored in history or
in the opened items DB data.
Release Notes:
- Handle external worktree entries [re]open better
Previously, we've only marked restored buffers as dirty. This PR changes
that behavior in case the buffer has been associated with a file and
that file has changed on disk since the last time Zed stored its
contents.
Example timeline:
1. User edits file in Zed, buffer is dirty
2. User quites Zed with `cmd-q`
3. User changes file on disk: `echo foobar >> file.txt` or `git checkout
file.txt`
4. User starts Zed
5. File/buffer are now marked as having a conflict (yellow icon)
Release Notes:
- Unsaved files that are restored when Zed starts are now marked as
having a conflict if they have been changed on disk since the last time
they were stored.
Demo:
https://github.com/user-attachments/assets/6098b485-b325-49b7-b694-fd2fc60cce64
This adds the ability for Zed to restore unsaved buffers on restart. The
user is no longer prompted to save/discard/cancel when trying to close a
Zed window with dirty buffers in it. Instead those dirty buffers are
stored and restored on restart.
It does this by saving the contents of dirty buffers to the internal
SQLite database in which Zed stores other data too. On restart, if there
are dirty buffers in the database, they are restored.
On certain events (buffer changed, file saved, ...) Zed will serialize
these buffers, throttled to a 100ms, so that we don't overload the
machine by saving on every keystroke. When Zed quits, it waits until all
the buffers are serialized.
### Current limitations
- It does not persist undo-history (right now we don't persist/restore
undo-history regardless of dirty buffers or not)
- It does not restore buffers in windows without projects/worktrees.
Example: if you open a new window with `cmd-shift-n` and type something
in a buffer, this will _not_ be stored and you will be asked whether to
save/discard on quit. In the future, we want to fix this by also
restoring windows without projects/worktrees.
### Demo
https://github.com/user-attachments/assets/45c63237-8848-471f-8575-ac05496bba19
### Related tickets
I'm unsure about closing them, without also fixing the 2nd limitation:
restoring of worktree-less windows. So let's wait until that.
- https://github.com/zed-industries/zed/issues/4985
- https://github.com/zed-industries/zed/issues/4683
### Note on performance
- Serializing editing buffer (asynchronously on background thread) with
500k lines takes ~200ms on M3 Max. That's an extreme case and that
performance seems acceptable.
Release Notes:
- Added automatic restoring of unsaved buffers. Zed can now be closed
even if there are unsaved changes in buffers. One current limitation is
that this only works when having projects open, not single files or
empty windows with unsaved buffers. The feature can be turned off by
setting `{"session": {"restore_unsaved_buffers": false}}`.
---------
Co-authored-by: Bennet <bennet@zed.dev>
Co-authored-by: Antonio <antonio@zed.dev>
Also improved multi statements to allow out of order parameter binding in statements
Ensured that all statements are run for maybe_row and single, and that of all statements only 1 of them returns only 1 row
Made bind and column calls add useful context to errors
Co-authored-by: kay@zed.dev
