[Bug]: t3 doctor database repair took the service offline for 72 minutes on a 12.8 GB database, with no warning or progress #29941

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Database growth and deleted-thread history are already tracked in #28903 and #17845, and background compaction cost in #26224. This report covers only how long the t3 doctor repair takes and how little it tells the user.

Area

apps/server

Steps to reproduce

1. Have a roughly 12–13 GB statev2.sqlite on a host running the background service.
2. Run t3 doctor and run the "Reclaim database space" repair.
3. Wait for the service to come back.

Expected behavior

The repair finishes in about the time it says it will ("This can take several minutes..."), or it warns about long downtime before stopping the service and shows progress while it runs.

Actual behavior

The service was down for about 72 minutes:

23:07:08  systemd: Stopped T3 Code server
00:18:56  systemd: Started T3 Code server
00:19:08  server log: Listening on http://0.0.0.0:3773

Before it starts, the repair doesn't estimate the duration. As far as I can tell from the code, it logs nothing between "Reclaiming database space. This can take several minutes..." and "Done", so a long run looks the same as a hung one. All threads and agents on the host are unavailable until it finishes.

The file is still large afterwards because most of it is live data:

I don't know which step takes the time. In this build, DatabaseMaintenance.compact runs verify, an unpaced compactEventStore, verify again, VACUUM, rebuildMessageSearch and wal_checkpoint(TRUNCATE). Comparisons that suggest VACUUM may not be the whole cost, though neither comes from this hardware:

• PR perf(server): return freed database pages to the filesystem #29811 measures VACUUM at about 11 ms per live MB, which would be about 2.4 minutes for this file.
• A rehearsal on a disposable copy of a 9.98 GB database took 899.6 s and reduced it by 3.42%.

PR #29806 would remove verify from this path and PR #29811 would make the repair rarer, but neither adds a warning or progress output.

Impact

Major degradation or frequent failure

Version or commit

0.1.7-nightly.20261102.4093

Environment

Linux x86_64 (kernel 6.8), QEMU VM, headless server running as a systemd user service.

Logs or stack traces

The timings above are the relevant logs. I didn't keep the terminal output, so I can't give doctor's before and after sizes or its count of removed events. The 72 minutes is the service downtime from the journal, which matches the reporter's own "more than an hour" for the run.

Workaround

None for the duration. On a database that already has incremental auto_vacuum and no free pages, doctor doesn't offer this repair, so there's no reason to expect a repeat until free pages build up.

Suggested improvements:

• Show an estimate based on database size before stopping the service.
• Report progress for each step.
• Time each step, so reports like this can say where the time goes.