ComfyUI 0.39: give foreground asset writes a turn

The contention is inside the local machine

An asset library is useful only if a file saved by a foreground generation becomes visible and traceable. It also needs a background scan to discover a pre-existing model, input, or output directory. Those jobs meet at the database writer. SQLite's WAL documentation permits readers alongside a writer, but says that only one writer can proceed at a time.

The October 5 UTC ComfyUI 0.39 release includes a connected asset change. PR #16748 changes the scan from 500 to 200 records per write transaction and puts a 0.12-second gap between non-final batches. The narrow aim is to let an upload registration or output record take the writer turn. It is not a generic database framework.

1. 1Foreground: upload or generated output
2. 2register asset
3. 3needs the one SQLite writer

1. 1Background: discover files
2. 2batch of asset rows
3. 3commit
4. 4yield before the next batch

1. 1SQLite WAL: readers may continue
2. 2one writer at a time
3. 3foreground writer can acquire the gap

1. 1Prompt queue has work
2. 2background scan stays paused

1. 1Prompt queue becomes empty
2. 2background scan resumes

This is an original conceptual diagram. It shows ownership of the scarce resource: the write turn. It does not claim that all filesystem work, image generation, or network access is serialized by SQLite.

What changed, and what it costs

The patch selects synchronous=NORMAL only after WAL is confirmed. The direct contract is SQLite's synchronous reference: in WAL mode, NORMAL remains consistent and resists corruption, but a committed transaction can roll back after a power loss or system crash; application crashes are a separate case. FULL adds a WAL sync after each commit. This is a durability decision for output links, tags, and renames, not a setting to hide a lock error.

The release also includes PR #16765: after a prompt finishes, the scan resumes only when the queue is empty. Queued work keeps it paused. The scan can therefore finish later under steady interactive use; the chosen trade-off is foreground availability over the shortest first scan.

The authors report storage and load measurements in #16748. They are author measurements, not reproduced results or a forecast for another machine. This article did not run ComfyUI, an asset scan, an upload, or those measurements.

Observe a local library without leaking its paths

The related PR #16719 adds CPU/paused counters and directory/file counts alongside the existing elapsed time, plus a closed error_kind. Its stated design derives a category from SQLite codes, fixed messages, or OS error numbers instead of exception text. That reduces the chance that a diagnostic event carries a path or user name; it is not a privacy audit.

Use the fields to distinguish three cases before changing anything: high paused time can mean foreground work was given priority; high elapsed time with lower CPU time can indicate waits; an explicit failure category names a class to investigate. Do not infer a device-wide performance regression from one scan, or publish raw path-bearing exceptions to a shared log. The source's reporting contract is local to this release and is not an independent privacy audit.

ComfyUI's current security policy describes a local default bind to 127.0.0.1. That policy does not establish that an instance exposed through a reverse proxy, shared machine, or public network has a safe authorization boundary. The repository code is GPL-3.0; model weights, custom nodes, images, prompts, and separately downloaded software need their own terms and trust review.

A deliberately unexecuted disposable-library exercise

This is an original exercise. It has not been run. Do not apply a PRAGMA to an existing library, and do not use a personal production output directory. First create a disposable local library and a small directory containing files that are safe to delete. Record the ComfyUI version, operating system, filesystem type, database location, whether WAL was already enabled, the number of files, and the exact foreground action to try. Do not copy the release's storage numbers into this record.

1. Start with the release's normal configuration; do not set synchronous=NORMAL yourself. Begin one initial scan and perform one harmless foreground save or upload.
2. Capture only the defined scan fields and the outcome of the foreground action. Keep paths, prompts, images, tokens, and exception text out of a shared note.
3. Repeat once with an empty prompt queue and once while a second prompt remains queued. The expected policy distinction is whether the background scan is eligible to resume, not a promised elapsed time.
4. Mark the exercise failed if the foreground save disappears from the asset library, the event lacks a usable category, the test touches a non-disposable library, or a durability setting changes without an explicit operator decision. Stop rather than adding a second database or a permissive fallback.

Local scan and upload observation need no model generation. Comparing prompt-queue states needs an already approved test workflow; do not acquire a new model or paid service for this exercise. Record local CPU, disk use, and elapsed time separately from any later generation cost.

If an operator later chooses a different durability policy, make that a documented deployment decision with a backup and recovery plan. It is not a tweak to hide a lock error. The useful mental model is small: WAL improves reader/writer overlap, a writer still has one turn, and the product must decide whose turn matters when interactive work and indexing meet.