Skip to content

Looper v2.14.174

Choose a tag to compare

@github-actions github-actions released this 13 Nov 04:46
· 127 commits to main since this release
6b772d2

Looper v2.14.174

This is the patch release v2.14.174, a hotfix line in which each merged change ships at once. It documents one change: #1321 (Lark catch-up reads a bounded set of threads).

Release Decision

Who should upgrade: Installations that use the Lark CLI channel in busy group chats or topics, where startup catch-up could fail the chat every time. Others need not upgrade.

What this release solves: #1321 (fixes #1315) bounds the thread discovery of Lark startup catch-up and stops one failing thread from failing its chat.

Breaking changes: No. There is no schema or API change. Behavior narrows on purpose (maintainer decision, see Behavior changes): catch-up no longer recovers old threads in which this channel was not active. The bridge boundary is unchanged: upgrade to v2.13.165 first if the installation is older.

How to verify: Check the installed version.

looper --version   # looper 2.14.174

Contributors: Maintainer @foolzzz authored #1321; no community contribution was included in this release.

Upgrading

The bridge boundary is unchanged: an installation older than v2.13.165 must upgrade to v2.13.165 first (upgrade to v2.13.165 first) and be started once; see the Upgrading section of the v2.14.0 release for the steps and rollback. An installation on v2.14.0 to v2.14.173 upgrades directly. There is no database migration; the Lark channel's local inbox file creates its new thread_activity table on the first start (CREATE TABLE IF NOT EXISTS).

Behavior changes

Read in the code of #1321:

  • Bounded thread discovery (looper/agents/channels/lark.py). For each chat, catch-up scans roots newest first and stops at the first root older than 24 hours (up to 5 pages of 50). Candidates also include threads this channel handled or sent a message in during the last 7 days. These come first. At most 50 distinct threads per chat are listed, 4 at a time. Dropped threads log threads_skipped. Reaching the root page cap logs an INFO count and completes the chat's window. Replies inside chat-level pages are no longer followed into threads one by one; threads come from the candidate set.
  • A thread failure no longer fails the chat. A failed thread listing logs its id and counts thread_failures; pages already read are still admitted, oldest first, and the chat's window is completed. A failed root discovery or chat listing still counts as a failure of the chat and leaves its window unfinished.
  • Stricter age check. A recovered message older than the recovery start is counted as too old (before, it was skipped silently). The first old reply that stops a thread listing is counted too. The lark_catchup INFO summary gains threads_scanned, thread_failures and thread_roots_capped.
  • Thread activity is remembered (looper/agents/channels/lark_inbox.py, looper/agents/channels/lark_transport.py). A handled message with a thread id, and a send or reply by this channel into a thread, store (chat, thread, time) in the channel's local inbox, pruned after 7 days and capped at 1,000 entries. When a send's CLI output lacks the thread id or chat id, the transport makes one extra GET of the sent message as the bot to read them; a failure there only logs a warning and never retries the send. History events now carry thread_id.
  • Internal. list_threads returns roots (with times) instead of threads; the p2p case returns no roots. docs/architecture/agent-system.md describes the rule. The bot-token channel is unchanged.
  • Model-visible changes: None. Prompts, tool schemas and the Manager's tools are unchanged; the only effect is that recovered thread messages reach the Manager as before, but from the bounded set.

Optional Capability Activation & Use

No new optional capability activation is introduced in this release.

Validation

Reported by the pull request: #1321 reports the tests that cover the change (tests/test_lark_catchup.py, tests/test_lark_history_transport.py, tests/test_lark_transport.py, tests/test_lark_cli_commands.py), automated reviews, and CI before the merge. It does not report a local full suite or the result of the reviews.

CI: CI runs after the release is drafted; its result is not recorded here.

Not tested for this draft: a local full suite, a real Lark catch-up against a busy chat and the built wheel. The release documentation gate checks the body only.

中文摘要

本版本是 patch release v2.14.174(热修线,每个合并的改动立即发布),说明一项改动:#1321(Lark 追补只读取有界的线程集合)。

升级决策

**谁需要升级:**在繁忙的群聊或话题中使用 Lark CLI 渠道、启动追补每次都会失败的安装。其他安装无需升级。

解决了什么:#1321(修复 #1315)为 Lark 启动追补的线程发现设置上限,并且单个线程失败不再导致整个聊天失败。

**是否有破坏性变更:**无。没有 schema 或 API 变更。行为有意收窄(维护者决定,见行为变化):追补不再恢复本渠道未参与过的旧线程。桥接边界不变:早于 v2.13.165 的安装须先升级到 v2.13.165。

**如何验证:**核对版本为 2.14.174。

**贡献者:**维护者 @foolzzz 提交 #1321;本版本无社区贡献。

looper --version   # looper 2.14.174

升级

桥接边界不变:早于 v2.13.165 的安装必须先升级到 v2.13.165 并启动一次(upgrade to v2.13.165 first 即先升级到 v2.13.165),步骤与回退见 v2.14.0 发布说明的升级一节。v2.14.0 至 v2.14.173 上的安装可直接升级。没有数据库迁移;Lark 渠道的本地 inbox 文件会在首次启动时创建新的 thread_activity 表(CREATE TABLE IF NOT EXISTS)。

行为变化与入口

以下在 #1321 的代码中可见:

  • 有界的线程发现(looper/agents/channels/lark.py)。每个聊天按从新到旧扫描根消息,遇到第一条早于 24 小时的根即停止(最多 5 页、每页 50 条)。候选还包括本渠道在最近 7 天内处理过或发送过消息的线程,并排在前面。每个聊天最多列出 50 个不同的线程,同时最多 4 个在读取。被舍弃的线程记录 threads_skipped。达到根页数上限时记录 INFO 计数并完成该聊天的窗口。聊天页内的回复不再逐条追入线程,线程来自候选集合。
  • **线程失败不再使聊天失败。**线程列表失败时记录其 id 并计入 thread_failures;已读取的页仍按线程内从旧到新的顺序处理,聊天窗口照常完成。根发现失败或聊天自身的列表失败仍算该聊天的失败,其窗口保持未完成。
  • **更严格的时间检查。**早于恢复起点的消息现在计为 too-old(原先静默跳过);使线程列表停止的第一条旧回复也会计入。启动时的 lark_catchup INFO 摘要新增 threads_scanned、thread_failures 和 thread_roots_capped。
  • 记住线程活动(looper/agents/channels/lark_inbox.py、looper/agents/channels/lark_transport.py)。已处理且带线程 id 的消息,以及本渠道在线程中的发送或回复,会把(聊天、线程、时间)存入渠道本地 inbox,7 天后清理,上限 1,000 条。当发送的 CLI 输出缺少线程 id 或聊天 id 时,传输层会额外以 bot 身份 GET 一次已发送的消息来读取;该步骤失败只记警告,不会重试发送。历史事件现在携带 thread_id。
  • 内部。list_threads 返回带时间的 roots,不再返回 threads;p2p 返回空。docs/architecture/agent-system.md 描述了该规则。bot-token 渠道不变。
  • **面向模型的变化:**无。提示词、工具 schema 和 Manager 的工具均未改变;恢复的线程消息照旧送达 Manager,只是来自有界集合。

可选能力启用与使用

本版本未新增可选能力启用入口。

验证

PR 报告的:#1321 报告了覆盖该改动的测试(tests/test_lark_catchup.py、tests/test_lark_history_transport.py、tests/test_lark_transport.py、tests/test_lark_cli_commands.py)、自动评审,以及合并前的 CI。未报告本地完整套件,也未报告评审结果。

**CI:**发布草稿后 CI 会运行,其结果未在此记录。

**本次草稿未测试:**本地完整套件、针对繁忙聊天的真实 Lark 追补以及构建出的 wheel。发布文档 gate 只检查正文。