ComfyUI 0.39：前景のアセット書き込みに順番を渡す

競合はローカルの中で起きる

アセットライブラリが役に立つのは、前景で生成・保存したファイルが見つかり、追跡できるときである。同時に、既存のモデル、入力、出力のディレクトリを背景で走査する必要もある。この二つはデータベースの書き込み枠で出会う。SQLiteのWAL資料は、読み取りと書き込みの並行を可能にする一方、同時に進められる書き込みは一つだけだと説明する。

10月5日UTCのComfyUI 0.39リリースには、関係するアセット変更が入る。PR #16748は、一度に書き込む件数を500から200へ変え、最後以外のバッチの間に0.12秒の空きを置く。アップロード登録や出力記録に書き込みの順番を渡すための、限定した変更である。汎用的なデータベース基盤ではない。

1. 1前景：アップロードまたは生成済み出力
2. 2アセット登録
3. 3SQLiteの唯一の書き込み枠が必要

1. 1背景：ファイル発見
2. 2アセット行のバッチ
3. 3commit
4. 4次のバッチの前に譲る

1. 1SQLite WAL：読み取りは並行できる
2. 2書き込みは一度に一つ
3. 3前景処理が空き枠を取得できる

1. 1プロンプトキューに仕事がある
2. 2背景走査は停止したまま

1. 1プロンプトキューが空になる
2. 2背景走査を再開する

この図は独自の概念図である。希少な資源、すなわち書き込みの順番を誰が持つかを示す。ファイルシステム全体、画像生成、ネットワークアクセスがSQLiteによって直列化されるという主張ではない。

何が変わり、何を失うか

このパッチはWALを確認した場合にだけsynchronous=NORMALを選ぶ。直接の仕様はSQLiteのsynchronous資料にある。WALのNORMALは一貫性と破損への耐性を保つ一方、停電またはシステムクラッシュ後にcommit済みトランザクションが戻る可能性がある。アプリケーションのクラッシュは別の条件である。FULLは各commitの後にWALを同期する。出力リンク、タグ、名称変更の耐久性を決める運用上の選択であり、ロックエラーを隠す設定ではない。

PR #16765も含まれる。プロンプトが完了した後、キューが空の場合だけ走査を再開し、待機中の仕事があれば止めたままにする。対話利用が続けば初回走査の完了は遅くなる。ここで選ぶのは、最短の初回走査より前景の書き込み可能性である。

#16748には作者自身のストレージと負荷条件による測定がある。独立した再現結果でも、別の機器への予測でもない。この教材ではComfyUI、走査、アップロード、測定を実行していない。

パスを漏らさずローカルライブラリを観察する

関連するPR #16719は、既存の経過時間に加え、CPU・停止時間、ディレクトリ・ファイル件数、固定されたerror_kindを追加する。資料の説明では、例外文ではなくSQLiteのコード、固定メッセージ、OSのエラー番号から分類する。診断イベントにパスや利用者名が混ざる可能性を減らすが、プライバシー監査ではない。

設定を変える前に、三つを区別する。停止時間が長いなら前景処理を優先した可能性がある。経過時間が長くCPU時間が低ければ待機を疑う。明示的な失敗分類は調べる対象の種類を示す。一度の走査から機器全体の性能劣化を断定せず、パスを含む例外文を共有ログへ出さない。この記録形式はこのリリースに属するもので、独立したプライバシー監査ではない。

現在のComfyUIのsecurity policyは、既定で127.0.0.1へbindするローカル利用を説明する。リバースプロキシ、共有機、公開ネットワーク経由で公開した場合に、安全な認可境界があることまでは示さない。リポジトリのコードはGPL-3.0である。モデルの重み、custom node、画像、プロンプト、別途取得するソフトウェアは、利用条件と信頼性を個別に確認する。

使い捨てのライブラリだけで行う未実行演習

これは独自の未実行演習である。既存のライブラリへPRAGMAを適用せず、個人の実運用の出力ディレクトリも使わない。まず、削除してよい少数のファイルだけを置いた使い捨てのローカルライブラリを用意する。ComfyUIの版、OS、ファイルシステム、データベースの場所、WALがすでに有効か、ファイル数、試す前景操作を記録する。リリース資料のストレージ測定値を自分の記録へ写さない。

1. リリースの通常設定から始め、自分でsynchronous=NORMALを設定しない。初回走査を一つ開始し、害のない前景の保存またはアップロードを一度行う。
2. 定義された走査フィールドと、前景操作の結果だけを記録する。パス、プロンプト、画像、トークン、例外文を共有メモへ入れない。
3. 空のプロンプトキューで一度、二つ目のプロンプトが残る状態で一度繰り返す。確認するのは背景走査を再開できる条件の違いであり、経過時間の保証ではない。
4. 前景で保存したものがアセットライブラリから消える、使える分類が記録されない、使い捨てでないライブラリに触れる、明示的な運用判断なしに耐久性設定が変わる場合は失敗とする。別のデータベースや寛容なフォールバックを加えず、そこで止める。

ローカルの走査とアップロードの観察に、モデル生成は必要ない。プロンプトキューの状態を比べる場合は、すでに承認された試験用ワークフローを使う。この演習のために新しいモデルや有料サービスを取得しない。ローカルのCPU、ディスク使用量、経過時間は、後で発生する生成費用と分けて記録する。

将来、耐久性の方針を変えるなら、バックアップと復旧計画を伴う運用上の判断として記録する。ロックのエラーを隠す調整ではない。考え方は小さい。WALは読み書きの重なりを改善するが、書き込みの順番は一つだけであり、対話処理と索引作成が出会ったときに誰を優先するかを製品が決める。