fix(session): 串行化 SQLite 会话写入#631
Conversation
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
| @@ -94,6 +98,14 @@ func (s *Service) executeAssistantToolCalls( | |||
| if !ok { | |||
There was a problem hiding this comment.
Medium: workerWG.Wait() now completes before any call to persistCompletedToolCallResult, which means EventToolResult, todo/facts updates, and remembered-state updates are all held back until every tool finishes. With calls like [slow, fast], the fast tool no longer surfaces its result when it completes; it is delayed behind the slow one. The PR description says only transcript persistence should become ordered, but this change also batches user-visible runtime events and state propagation for the entire tool phase.
| @@ -601,6 +623,9 @@ func (s *SQLiteStore) SaveAsset(ctx context.Context, sessionID string, r io.Read | |||
| if err := validateStorageID("session id", sessionID); err != nil { | |||
There was a problem hiding this comment.
Medium: SaveAsset takes the global writeMu before the full asset write path, including io.Copy, Sync, Close, and the rename. Because r can be slow and assets can be large, one upload now blocks every other session write in the workspace for the entire file I/O duration. The original bug was SQLite writer contention, but this lock scope serializes unrelated non-SQLite work as well and can noticeably stall transcript/title/state updates under load.
26ef0a3 to
e2a18d4
Compare
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
背景
运行中同一会话可能因为多个工具结果并发回灌、Gateway 管理写入口绕过 Runtime 会话锁等路径,同时竞争 SQLite 写事务,偶发触发
database is locked并中断当前会话。当前修改
SQLiteStore内增加单 writer 写锁,并将 SQLite 连接池收敛为单连接,避免同一工作区数据库多 writer 抢锁。.git误判、slash-rooted 路径解析。验证
git diff --checkgo test ./...CGO_ENABLED=1 go test -race ./internal/session ./internal/runtime