[Bug] agent_sub_stages 使用 asyncio.create_task 写入导致 SQLite database is locked

[jason9033]

What happened / 发生了什么

群聊环境下正常聊天bot有时会直接发送了下面这一段错误。我不太确定具体是因为Astrbot的问题还是我设备性能的问题。

Error occurred while processing agent request: (sqlite3.OperationalError) database is locked
(Background on this error at: https://sqlalche.me/e/20/e3q8)

我让bot帮我分析了一下。它说是在处理 Agent 请求时，服务端出现 SQLite 数据库被锁定的报错，导致部分 LLM 请求状态记录失败。检查代码发现在 agent_sub_stages.internal 记录 LLM 请求状态时，使用了 asyncio.create_task 将数据库写入操作放入后台并发执行。由于 SQLite 是基于文件锁的数据库，在面临高并发异步写入时容易产生锁冲突，从而抛出 database is locked 异常。

Reproduce / 如何复现？

群聊环境下正常聊天有概率出现这个问题

AstrBot version, deployment method (e.g., Windows Docker Desktop deployment), provider used, and messaging platform used. / AstrBot 版本、部署方式（如 Windows Docker Desktop 部署）、使用的提供商、使用的消息平台适配器

debian13 linux AstrBot Desktop v4.25.2

OS

Linux

Logs / 报错日志

Error occurred while processing agent request: (sqlite3.OperationalError) database is locked
(Background on this error at: https://sqlalche.me/e/20/e3q8)

Are you willing to submit a PR? / 你愿意提交 PR 吗？

• Yes!

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct。

[dosubot]

Hi @jason9033! I'm Dosu and I'm helping the AstrBotTeam team.

这个问题之前在 #6443 中已有报告，且已有部分修复合入。

问题根因

你的分析是正确的。在 agent_sub_stages/internal.py 中，asyncio.create_task 用于异步记录 Provider 统计数据（insert_provider_stat），不阻塞用户响应 [1]。在群聊高并发场景下，多个写入任务同时竞争 SQLite 文件锁，导致 database is locked。

当前已有的修复

当前代码已配置了 30 秒的 busy_timeout，让 SQLite 在锁冲突时等待而非立即报错 [2]：

connect_args = {"timeout": 30} if is_sqlite else {}

同时还启用了 WAL 模式等优化 [3]。

仍可能触发的场景

如果你在 v4.25.2 上仍然遇到这个错误，说明在你的群聊环境中写入并发量超过了 30 秒等待窗口能消化的范围，或者存在长事务占用锁的情况。可能的改进方向：

1. 为写入操作添加指数退避重试机制 — 在 _record_internal_agent_stats 中捕获 OperationalError 并重试
2. 使用全局写入队列 — 将所有后台数据库写入串行化，避免并发竞争
3. 降低写入频率 — 对统计数据做批量写入而非逐条写入

如果你打算提交 PR，建议优先考虑方向 1（重试机制），实现简单且对现有架构侵入最小。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[jason9033]

我注意到在4.21.0版本已经修复了类似问题
https://github.com/AstrBotDevs/AstrBot/releases/tag/v4.21.0
但我这边在4.25.2版本中还是能复现该问题

[dosubot]

确认一下情况：v4.21.0 的修复（PR #6474）添加了 30 秒的 busy_timeout，这个配置在 v4.25.2 中仍然存在且有效 [1] [2]。

但在 v4.21.0 之后，internal.py 中新增了 asyncio.create_task 的 provider 统计写入路径（_record_internal_agent_stats），这个写入操作没有重试机制 [3]。在群聊高并发场景下，如果多个 agent 请求同时完成并触发统计写入，加上对话历史更新等其他写操作，可能在极端情况下超过 30 秒等待窗口，导致你看到的 database is locked 错误。

所以你的问题本质上是：v4.21.0 的 busy_timeout 修复了旧的并发写入问题，但后续版本新增的统计记录功能引入了新的并发写入点，且缺少重试保护。

如果你要提 PR，建议在 _record_internal_agent_stats 中为 db_helper.insert_provider_stat() 调用添加简单的重试逻辑（捕获 OperationalError 后指数退避重试 2-3 次）。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Soulter]

后台有完整的报错日志吗？

[lxfight]

What happened / 发生了什么

群聊环境下正常聊天bot有时会直接发送了下面这一段错误。我不太确定具体是因为Astrbot的问题还是我设备性能的问题。

Error occurred while processing agent request: (sqlite3.OperationalError) database is locked (Background on this error at: https://sqlalche.me/e/20/e3q8)

我让bot帮我分析了一下。它说是在处理 Agent 请求时，服务端出现 SQLite 数据库被锁定的报错，导致部分 LLM 请求状态记录失败。检查代码发现在 agent_sub_stages.internal 记录 LLM 请求状态时，使用了 asyncio.create_task 将数据库写入操作放入后台并发执行。由于 SQLite 是基于文件锁的数据库，在面临高并发异步写入时容易产生锁冲突，从而抛出 database is locked 异常。

Reproduce / 如何复现？

群聊环境下正常聊天有概率出现这个问题

AstrBot version, deployment method (e.g., Windows Docker Desktop deployment), provider used, and messaging platform used. / AstrBot 版本、部署方式（如 Windows Docker Desktop 部署）、使用的提供商、使用的消息平台适配器

debian13 linux AstrBot Desktop v4.25.2

OS

Linux

Logs / 报错日志

Error occurred while processing agent request: (sqlite3.OperationalError) database is locked (Background on this error at: https://sqlalche.me/e/20/e3q8)

Are you willing to submit a PR? / 你愿意提交 PR 吗？

• Yes!

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct。

QQ 群聊吗，可以提供更详细的使用场景吗？

[zouyonghe]

I can reproduce/confirm this on v4.25.2 under Linux systemd with a high-traffic QQ group setup. Anonymized findings from journalctl:

• The user-facing error appears from agent_sub_stages.internal:423 as (sqlite3.OperationalError) database is locked.
• One observed failure happened exactly about 30s after acquired session lock for llm request, matching the configured SQLite busy timeout.
• The service had a single AstrBot Python process; no duplicate AstrBot service instance was writing the same DB.
• data_v4.db was in WAL mode, but some conversations.content rows were multi-MB JSON payloads, so writes can hold SQLite single-writer locks long enough to starve concurrent writes.
• A plugin SQLite DB also emitted database is locked, so the broader pattern is SQLite write contention under message/plugin concurrency.

I opened a small PR for one core contributor to this contention: retrying transient SQLite lock failures when the background internal provider stats write races with other DB writes.

PR: #8574