AstrBot

This is a known bug in AstrBot v4.19.2. Causes: (1) the qq_official adapter lacked message deduplication based on message_id, so QQ Official webhook retries (Tencent resends notifications up to 3 times if not acknowledged) were processed repeatedly; (2) adapter event handlers were not cleaned up when disabling the adapter in the UI, causing duplicate processing after restart. Fix: upgrade AstrBot to the latest version - PR #6320 fixed duplicate message processing caused by QQ Official webhook retries. Temporary workaround for older versions: fully restart the AstrBot process/container instead of toggling the adapter in the web UI, and avoid frequently enabling/disabling the adapter. Duplicate replies can trigger API rate-limit bans, so upgrading is strongly recommended.

Affected version: AstrBot 4.29.0-beta.1. The background-task wake-up turn bypasses the normal message pipeline and delivers output only when the main agent calls send_message_to_user. The old warning at astrbot/core/astr_agent_tool_exec.py:662 fired only when llm_resp was empty, so a normal response without a delivery attempt was completely silent.

Fix: upgrade to an AstrBot release containing PR #10398 (fixes issue #10395). On Windows desktop, update through AstrBotLauncher and restart. For a Git deployment:

cd AstrBot
git pull
# install/update dependencies as required by your deployment
# then restart AstrBot

Verify the fix with:

grep -n "_has_send_oper" astrbot/core/astr_agent_tool_exec.py

The fix checks cron_event._has_send_oper after runner.step_until_done() and get_final_llm_resp(). If the background task produced a result but nothing was delivered to the current conversation, AstrBot now logs a WARNING containing task_id and tool_name. The flag is set only after successful delivery, so failed sends or sends to another session are also detected.

No automatic resend is added because the model may intentionally stay silent. If you need guaranteed delivery, you must additionally implement a fallback that sends llm_resp.completion_text through the normal response path when _has_send_oper is false; this changes behavior and should be tested carefully.

Temporary mitigation on older versions: strengthen the main-agent prompt so that a completed background task with a meaningful result must call send_message_to_user, or manually add the _has_send_oper WARNING check near the existing if not llm_resp branch. The result is not lost from agent state—it is persisted as [BackgroundTask] ... Result: ... in conversation history—but the user is not notified.

This affects AstrBot v4.28.1. A root-relative plugin URL such as /api/v1/files/tokens/<token> is not recognized as a URL. MediaResolver treats it as a local file without checking existence, so Windows resolves it to C:\api\v1\...; the later read fails and the image is silently skipped.\n\nPermanent fix:\n1. Upgrade AstrBot to a release containing the PR Fix/reject unresolvable image refs for issue #10264. The framework now rejects unresolvable media references instead of returning a fake local path.\n2. Fix the plugin generating the URL—e.g. astrbot_plugin_qqwebui v1.1.0—so it returns an absolute HTTP URL, not a path beginning with /:\n\n``python\nimage.url = f'{PUBLIC_BASE_URL.rstrip("/")}/api/v1/files/tokens/{token}'\n# Example: http://127.0.0.1:6185/api/v1/files/tokens/<token>\n`\n\nValid media inputs are http(s)://..., an existing local file path, file://..., data:..., or valid Base64.\n\nIf you cannot upgrade immediately, patch the fallback branch in astrbot/core/utils/media_utils.py, inside _materialize_media_ref():\n\n`python\npath = Path(media_ref)\nif path.is_file():\n return _LocalMediaFile(path=path, mime_type=_guess_mime_type(path))\nraise ValueError(f'Unresolvable media reference: {media_ref}')\n`\n\nRestart AstrBot after the change. Old conversation history may still contain the invalid [Image Attachment: path ...]` placeholder; test with a newly sent image, including quoted and forwarded images, which use the same code path.

这是因为该插件在 main.py:52 中猴补丁了 aiocqhttp 的 call_action，但删除或卸载时没有在 terminate() 中还原。AstrBot 进程仍在运行时，内存中的 bot 对象还保留旧包装函数，所以调用栈会继续指向已删除的插件路径。解决方法是完整重启 AstrBot 进程；Docker 部署可执行 docker restart <AstrBot容器名>，原生部署则停止后重新启动服务。重启后确认 data/plugins/astrbot_plugin_temp_chat_fix 目录已删除即可。日志中的 retcode=100、no such temp session 表示 QQ 临时会话已失效，需要用户重新发起临时会话，这与插件残留报错不是同一个问题；应另行向 astrbot_plugin_temp_chat_fix 仓库反馈，让作者在 terminate() 中还原 call_action。

In AstrBot v4.28.2, the context compressor calls text_chat() without request_max_retries, so the provider uses its default of 5 total attempts with exponential backoff. HTTP 429 is retried, blocking the reply until all attempts fail. Switching the main model does not help because the stuck request is using the separately configured summary model. The fallback also calls truncate_by_halving() only once and does not recheck whether the remaining history fits.

Fix: upgrade to an AstrBot build containing PR #10436 (master after commit 800fdcc). That fix passes request_max_retries=1 to the summary request—1 means one total attempt, not zero—then immediately falls back to truncation. It preserves leading system messages, splits the remaining history into complete rounds, removes the oldest round repeatedly until the estimated context fits, keeps the latest round, and keeps tool calls paired with their tool results.

Temporary workarounds on v4.28.2:
1. Run /new to start a fresh conversation; this is confirmed to restore replies.
2. Restore the summary model quota/API credentials or configure an available summary model.
3. Disable independent LLM context compression if an unavailable summary model cannot be fixed immediately.

Switching only the main chat model is not a workaround because it does not change the summary model. If you later hit an API-confirmed context-overflow error involving tool calls, also use a build containing the paired record-pop fix from issue #7225.