Hacktoberfest 2026：维护者为十月标记出来的 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 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
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 天 9 小时
30 天内合并 PR
88

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

AltimateAI/altimate-code 的其他 Issue

查看 AltimateAI/altimate-code 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。