Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

sql_materialize holds the per-session scratch lock for the whole remote source read, blocking all other scratch work

オープン
  • 何か問題がありますか？
#1,485 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
30/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
sql, typescript
領域
databases, performance

調査の方向性

Start in packages/opencode/src/altimate/tools/sql-materialize.ts around lines 373-380 and 472-480 to see which work sits inside withScratchConnection, then read exclusive() and the per-session queue in packages/opencode/src/altimate/native/connections/scratch.ts. Done means preflight and the source read run outside the lock, only the write phase takes it, and a SELECT 1 on scratch returns in under a second during a slow materialize. The fix changes concurrency semantics, so confirm the design with maintainers first.

索引モデルが issue の本文から書いたものです。

説明

Problem

While one sql_materialize reads from a slow remote source, every other scratch operation in the session (sql_execute on scratch, sql_check, schema_inspect, another sql_materialize from a different source) queues behind it, including calls from sub-agents.

Mechanism

  • sql_materialize runs preflight() and executeSource() against the remote source inside withScratchConnection(...) (packages/opencode/src/altimate/tools/sql-materialize.ts:373-380).
  • That callback is exclusive() (packages/opencode/src/altimate/native/connections/scratch.ts:107), a single promise chain per root session shared by all sub-agents (:51-61, :170).
  • Only the write phase (BEGIN/CREATE/INSERT/COMMIT, sql-materialize.ts:472-480) needs the lock.
  • Reported tool durationMs includes queue time, which also misleads timing analysis.

Evidence

Recorded sessions:

  • One session was blocked for 1,464 s: three SQLite reads that take 0.6 s alone, issued from 4 parallel sub-agents, all finished together with a multi-minute remote read.
  • Other blocks of 706, 404, 376, 129 and 43 s; 10,753 call-seconds of waiting across 7 sessions, none of which produced a correct answer.
  • Up to 96 scratch calls in flight at once, completing in bursts; one-row COUNT(*) queries waited 140-280 s.
  • In another set of sessions 824 s of queueing across 59 sessions; a 4-row lookup waited 115 s behind an unrelated materialization; a 6-row aggregate took 48.7 s because it queued behind a 48.3 s materialization; an estimated 370 s of wall time lost in 89 generations.

Impact

Time (and, under a time budget, answers): it prevents fan-out from running in parallel and adds directly to budget pressure. Observed with both Claude Opus and gpt-5.6-sol sessions, worst under sub-agent fan-out.

Proposed fix

  • Run preflight and the source read outside the lock (stream to a staging file or buffer); take exclusive() only for the write phase.
  • Serve read-only scratch queries on separate DuckDB connections to the same file so reads do not queue behind writes.
  • Report queue_ms and exec_ms separately in tool metadata and traces.

Acceptance check

  • Test: while a materialize from a deliberately slow source is running, a SELECT 1 on scratch from another sub-agent returns in under 1 s.
  • Two concurrent materializations from different sources overlap their read phases.

Related: #1479 (Mongo byte-bounded reads fetched one document per round trip; fix in #1480).

主要言語
TypeScript
スター
810
フォーク
121
平均マージ
1日 10時間
マージ済み PR（30日）
89

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

AltimateAI/altimate-code のほかの issue

AltimateAI/altimate-code の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。