[only21mil]

Problem

The server's SQLite writer runs synchronously on the main thread. Inside a write transaction, a statement that changes more than 64 KiB of existing pages makes SQLite spill its statement journal to a new temp file. Large sorts do the same. Creating that file is a synchronous open on the event loop. On a busy disk, and on copy-on-write filesystems such as btrfs where a file create can wait for a filesystem commit, each one blocks every client request until it returns.

It happens during ordinary turns. With the mock ACP agent as the provider, 10 turns on a fresh state dir opened 29 temp files on the server's main thread. On a loaded btrfs host with a large database, /proc samples of a running server caught the main thread waiting in openat(O_TMPFILE) in 7 to 24% of its blocked samples, inside provider-event writes.

Change

Set PRAGMA temp_store = MEMORY on the server's writer connection, so statement journals and sort spills stay in memory. Each one takes the memory its temp file would have taken. In the run above those files peaked at 64 to 84 KiB each, median 72 KiB. westline-jordan's profile on #19105 saw one of at least 6.5 MB. An open savepoint keeps journal pages across the statements inside it, so large statements and open savepoints can increase peak memory use.

The pragma is set in layerSetup, on the writer connection and before migrations run; the reader worker keeps its temp files on disk, off the main thread. t3 doctor opens its own connection for VACUUM, which keeps its temp copy of the database on disk as before. Background event compaction deletes in pages of 50 events, so its statements stay small.

This takes one source of main-thread file I/O off the event loop. Stalls are reduced, not gone: WAL writes, checkpoint-related syncs and cold page reads still run on the writer on the main thread.

Scope and approval

No triaged issue covers this exact cause. Related: #15707, a triaged and now closed report of V2 event writes stalling the server on a slow disk. On #19105, westline-jordan measured SQLite temp files at 17% or more of the bytes the server writes and suggested temp_store = MEMORY, untested. This PR tests that suggestion and measures its memory cost.

I'm submitting it as a small, focused fix: one pragma on the server's writer, no schema, contract or client change. I can open an issue first if you prefer.

Verification

Test: keeps a write transaction's statement journal off the temp directory in apps/server/src/persistence/Sqlite.test.ts. It opens a file-backed database through SqlitePersistence.layerFromPath, runs a 256 KiB multi-row UPDATE in a transaction, and lists open, deleted etilqs_* files in /proc/self/fd. It matches SQLite's file name, not a directory, because SQLite falls back to /var/tmp when TMPDIR is unset while os.tmpdir() is /tmp. Linux only, since it reads /proc.

• Main 66ee628e08 with this test: fails, with TMPDIR set and unset. The probe finds one open statement journal.
• This branch: passes, with TMPDIR set and unset.
• vp run check:changed 66ee628e08: format, lint, knip, graphql, typecheck and the changed test file pass.

Vitest on main 66ee628 with this branch's test added. The new test fails: SQLite has one statement journal open in /var/tmp.

The same command on this branch. Both tests in the file pass.

Runtime check: the server ran from source on a fresh state dir, with the repo's mock ACP agent (apps/server/scripts/acp-mock-agent.ts) as the only provider and strace -f -y -e trace=openat,pwrite64 on the server process. One thread got 10 turns with 98 KB replies through t3 thread start and t3 thread send --wait. All 10 turns completed on both builds.

Temp files the server opened during 10 mock-agent turns: 29 on main, all on the main thread, and none on this branch.

Nothing in the UI changes, so there are no screenshots.

Not checked:

• macOS and Windows. The test skips there, and the runtime check ran only on Linux.
• Peak memory for one-off large statements, such as a migration rewriting a big table inside a transaction, and for open savepoints or nested transactions, which keep journal pages across the statements inside them.
• Client latency on a slow disk with only this change applied.

Prior PRs

• perf(server): stop creating a SQLite temp file for every orchestration command #14403 by haseeb-asad removed a savepoint that pushed every V1 orchestration command's statement journal past 64 KiB into a temp file. It was closed when the V2 orchestrator replaced that code. This PR addresses the same temp files on V2's write path.
• westline-jordan's measurement on [Bug]: Desktop server writes ~100× its event data to disk (327 GB in 21 h, ≥2.2 TB in 15 h on Oct 8) #19105 first pointed at temp_store = MEMORY for these files.

Fix, tests, PR description and images by Claude Opus 5.5 in T3 Code Nightly.

🤖 Generated with Claude Opus 5.5 in T3 Code Nightly

[macroscopeapp]

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — The PR changes the server writer's SQLite default so temporary journals and sort data use memory instead of disk, altering existing runtime behavior and peak-memory characteristics. A Linux regression test covers the intended file-I/O behavior, but the product-default change warrants human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Warning

Review limit reached

Only developers with an assigned seat can use this organization's usage-based review budget, and seats here are assigned manually. Ask an admin to assign a seat, or change the review continuation mode in Billing.

Next included review available in 1 minute.

Check out review usage here.

View limit details

Limit details: You’ve used all 10 included reviews currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 6a3a460
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 797624ff-d75d-47c0-9f57-e91f90484f37

Commits

Reviewing files that changed from the base of the PR and between faef742 and 27a34b0.

Files selected for processing: 2

• apps/server/src/persistence/Sqlite.test.ts
• apps/server/src/persistence/Sqlite.ts

No actionable comments were generated in the recent review.

ℹ️ Recent review info

⚙️ Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 171f8d8
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 575d1f6b-6d58-4946-aafa-6b686df75c5c

📥 Commits

Reviewing files that changed from the base of the PR and between 171f8d8 and faef742.

📒 Files selected for processing: 2

• apps/server/src/persistence/Sqlite.test.ts
• apps/server/src/persistence/Sqlite.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

Walkthrough

SQLite setup now stores temporary data in memory. A Linux-only persistence test checks whether a large transaction leaves deleted statement-journal files open.

Changes: SQLite temporary storage

Layer / File(s)	Summary
Memory-backed temporary data and regression test apps/server/src/persistence/Sqlite.ts, apps/server/src/persistence/Sqlite.test.ts	layerSetup sets temp_store to MEMORY. A Linux-only test checks for new open deleted etilqs_* files after a multi-row update and removes its temporary database directory.

Priority: Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related issues

• pingdotgg/t3code#24003: The issue identifies SQLite temporary-file writes and suggests PRAGMA temp_store = MEMORY; this change applies that setting.
• pingdotgg/t3code#23000: The setting can affect temporary data used by query plans, but this change does not add indexes or change scan behavior.
• pingdotgg/t3code#23365: The issue lists PRAGMA temp_store = MEMORY as a mitigation for temporary-file writes; this change applies that mitigation but does not change snapshot persistence or commit frequency.

Possibly related PRs

• pingdotgg/t3code#24145: It addresses statement-journal spills through batched snapshot writes, while this PR uses memory-backed temporary storage.

Suggested reviewers: t3dotgg, macroscopeapp

Merge Risk: Minimal · up to faef7

The change addresses the reported main-thread SQLite temporary-file behavior without an established merge-blocking defect.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the primary change: preventing SQLite temporary files from blocking the server event loop.
Description check		The description includes complete Problem, Change, Scope and approval, and Verification sections. It explains the cause, implementation, scope, test evidence, runtime results, limitations, and agent a…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description includes complete Problem, Change, Scope and approval, and Verification sections. It explains the cause, implementation, scope, test evidence, runtime results, limitations, and agent attribution.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

@only21mil, kept your implementation, regression test, and all three commits. merged current main (6a3a460b09) and shortened the source explanation to two lines. the final diff is 48 added lines across two files: one writer pragma, its memory tradeoff, and your existing linux regression. reader workers and doctor's offline vacuum retain their settings; main's checkpoint worker remains intact.

verification on 27a34b0480869e613fb30b845607982786aa0911:

• reproduced the regression on current main with your test: one open deleted /var/tmp/etilqs_* statement journal. the same test passes with the pragma.
• blacksmith: all 22 persistence, sqlite adapter, and database-maintenance tests passed. vp run check:changed passed format, lint, knip, graphql, typechecks, and adjacent tests.
• runtime: cli → server → mock acp provider completed 10 large-reply turns. returned replies were capped at 65,536 characters; persisted event payloads reached 66,798 bytes. strace -f -e trace=openat recorded zero etilqs_* opens. database integrity_check returned ok.
• github ci is green, including all eight server shards, lint, build/typecheck, tests, and the final check. two independent code reviews approved this exact head without findings. the latest coderabbit check reports success but its review was rate limited; the earlier review had no actionable findings.

unverified: macos/windows, peak memory for large statements or open savepoints, and client latency on a slow disk. no latency improvement is claimed from this runtime check. no ui rendering changed. the remaining human decision is accepting the documented memory tradeoff. task-owned server and testbox are stopped.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified unchanged head 27a34b0480869e613fb30b845607982786aa0911 on linux, against github/main at 49a9e80e0b. used separate fresh state directories, one background dev server at a time, and a project pointing at a real git repository. no mocks, fixtures, replay provider, or direct database writes.

• reproduced on main through t3 project add and t3 thread start/send --wait, using real codex gpt-6.1-sol through the local provider proxy. six turns completed, including a shell read and five roughly 105 kb user messages. strace -ff -tt -y -e trace=openat observed seven etilqs_* opens on the server's main thread.
• ran the identical six-turn workload on the pr: all completed, with zero etilqs_* opens on the server's main thread. the subsequent web ui edit turn also produced none.
• drove chrome with the repo's playwright dependency: selected the thread, submitted a follow-up through the composer, watched codex edit README.md, and saw SQLITE_UI_EDIT_OK with a one-line diff. its checkpoint was ready.
• restarted the server, reopened the thread with the existing browser session, and opened the persisted diff. a resumed codex turn read the edited file and returned SQLITE_RESTART_OK.

short runtime transcript:

main: completed runs=6; ready checkpoints=7; integrity_check=ok
main writer tid 14327: etilqs opens=7
04:20:57.264212 openat(..., "/var/tmp/etilqs_ef3e28121791e294", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 48
pr writer tid 20482: etilqs opens=0
pr: matching runs 1-6 completed; web edit run 7 completed
restart: run 8 completed; reply=SQLITE_RESTART_OK
pr: completed runs=8; ready checkpoints=9; integrity_check=ok

blacksmith passed all 22 existing sqlite adapter, persistence, and database-maintenance tests. vp run check:changed 6a3a460b09e70f06eebfd46ad304c74b96afa179 passed format, lint, knip, graphql, affected typechecks, and adjacent tests. no code changes or pushes were needed.

Not verified

native ios/android, electron, macos/windows, remote relay/tunnel connections, and other providers. slow or loaded btrfs latency, peak memory under large migrations/savepoints, and large sort spills were not measured. this proves removal of the observed writer temp-file opens during real turns; it makes no latency or peak-memory claim.