[Plugin] astrbot_plugin_listen_github

[aliveriver]

插件信息

{
  "name": "astrbot_plugin_listen_github",
  "display_name": "监听github平台用户公开动态",
  "desc": "通过 RSS 定时获取 GitHub 用户/仓库动态并推送到聊天会话",
  "author": "aliveriver",
  "repo": "https://github.com/aliveriver/astrbot_plugin_listen_github",
  "tags": [
    "视奸",
    "github"
  ],
  "social_link": "https://github.com/aliveriver"
}

插件检查清单

• 我的插件经过完整的测试
• 我的插件不包含恶意代码
• 我已阅读并同意遵守该项目的 行为准则。

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_listen_github

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. 动态监听的去重键设计有逻辑冲突（高风险功能缺陷）
   cmd_watch_list 是按会话（umo）存储的，但 _fetch_new_entries 使用的 kv_key 是 user_{username}（全局共享）。
   结果：同一用户被多个会话监听时，先轮询到的会话会更新 last_entry，后面的会话可能收不到本应收到的更新。
   同时它也会与全局配置中的同名用户监听互相“抢游标”。

2. _get_cmd_watch_list 的返回类型不稳，可能导致轮询崩溃（中高风险健壮性问题）
   当 KV 中存的是字符串且 JSON 解析后不是 dict（例如 []），函数会直接返回该对象。
   _do_poll 随后调用 cmd_watch_list.items()，会抛异常。虽然外层有 try/except，但会导致该轮询周期整体失败。

3. 首次启动会推送历史积压消息（中风险业务逻辑问题）
   对 JSON 配置里的监听项（cfg_watch_users/cfg_watch_repos/cfg_watch_repos_commits）没有初始化 last_entry。
   首次轮询会把近期历史条目当“新消息”推送，容易造成群内刷屏。

4. gh_list 未覆盖 Commit 监听配置，展示不完整（功能缺陷）
   插件支持 watch_repos_commits，但 gh_list 中：

   • “全局配置”判断条件没包含 self.cfg_watch_repos_commits
   • 列表输出也没显示 commit 监听项
     会造成“已配置但列表看不到”的误导。

5. 网络会话创建方式低效（异步性能问题）
   _fetch_feed 每次请求都新建 aiohttp.ClientSession()。在轮询多目标时会频繁建连、DNS、TLS，增加资源开销并影响吞吐。
   建议复用插件级 ClientSession（初始化创建，terminate 关闭）。

6. 轮询发送串行执行，目标多时延迟放大（性能与可维护性问题）
   _do_poll 对每个目标、每个会话逐个 await send_message，整体完全串行。会话或监听项数量上来后，单轮耗时显著上升，实际轮询周期会被“拉长”。

7. 时间解析逻辑存在无效分支（可读性/维护性问题）
   _convert_time 里这段：

   if hasattr(feedparser, "_parse_date") and hasattr(feedparser._parse_date, "__call__"):
       pass
   return time_str

   实际没有做任何解析，属于“看起来要兜底、实际上没工作”的死分支，容易误导维护者。

8. 存在未使用导入（代码质量问题）
   MessageEventResult 被导入但未使用，增加噪音。

---

代码评审团

人物一：Linus Torvalds（直截了当型）
你这个 last_entry 键是“全局变量伪装成会话变量”的典型事故现场。多会话监听同一用户时互相踩状态，这不是边角 bug，是核心语义错位。先把状态隔离设计好（至少 umo + target 级别），再谈功能扩展。

人物二：Steve Jobs（产品体验型）
用户看到“我明明配了 commit 监听，/gh_list 却没显示”，这会直接破坏信任。还有首次启动就推历史消息，体验像“通知爆炸”。产品感知上，这两件事比你多写几个命令更致命。

人物三：Geralt of Rivia（务实猎魔人型）
我闻到了性能怪物的味道：每次抓 feed 都新建 ClientSession，发送还全串行。目标一多，轮询就变“慢性中毒”。把会话复用起来，能并发的地方并发，别让任务循环自己拖死自己。

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[aliveriver]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_listen_github

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. 首次初始化游标逻辑存在“失败即已初始化”问题（功能正确性）
   在 _init_cursors() 中，即使 _fetch_feed() 失败或返回空，也会执行 put_kv_data(init_flag, "1")。
   结果：后续不再重试初始化，last_entry 可能为空，下一轮会把历史内容当“新动态”推送，违背“防止首次启动推送历史消息”的目标。
   建议：仅在成功获取并写入游标后再写 initialized=1；失败时保留未初始化状态，下次重试。

2. _fetch_feed 存在潜在 ClientSession 资源泄漏（异步最佳实践）
   当 self._http_session 为 None 时会临时创建 aiohttp.ClientSession(...)，但没有关闭。
   建议：

   • 要么强制插件生命周期中始终复用 self._http_session；
   • 要么临时会话使用 async with aiohttp.ClientSession(...) as session: 自动关闭。

3. 时间解析仅使用 published，可能丢失大量 Atom 条目时间（逻辑完整性）
   GitHub Atom 常见字段是 updated。当前 _fetch_new_entries() / gh_check() 只读 published，会出现时间为空。
   建议：改为 entry.get("published") or entry.get("updated")。

4. max_entries 缺少合法性校验（边界条件）
   max_entries 未限制下界，若配置为负数，切片语义会异常（如 [: -2]），导致结果不可预期。
   建议：初始化时做归一化：self.max_entries = max(0, int(...))。

5. 新动态扫描窗口固定为 max_entries * 2，存在漏消息风险（潜在缺陷）
   在 _fetch_new_entries() 中，如果两次轮询间新增条目很多，且旧游标不在扫描窗口内，会提前截断并更新到最新 ID，导致中间动态永久丢失。
   建议：

   • 至少扫描到命中 last_entry_id 为止（可设置硬上限防止过大）；
   • 或采用分页/游标策略，避免“窗口截断 + 游标前移”组合造成数据丢失。

6. gh_check 的仓库检查与文案存在语义偏差（可维护性/可用性）
   文案写“仓库最新动态”，但实际只查 releases.atom，不含 commit/activity。
   建议：

   • 明确文案为“最新 Release”；
   • 或提供参数选择 release/commit，两者都支持。

7. 存在未使用导入和变量（代码质量）
   json, Dict, MessageEventResult 以及 _do_poll 中 keys 未使用。
   建议：删除无用代码，降低维护噪音。

---

代码评审团

人物一：Linus Torvalds（直接、硬核）
“你这轮询逻辑最危险的不是报错，而是悄悄丢数据：max_entries*2 扫描窗口 + 游标更新到最新，典型的‘看起来稳定，实际上漏事件’。先保证不丢，再谈优雅。”

人物二：史蒂夫·乔布斯（产品体验导向）
“命令是用户界面的一部分。gh_check repo 用户理解的是‘仓库动态’，你返回的是‘仅 Release’。这就是体验断层。把能力和文案对齐，用户才会信任这个插件。”

人物三：Tony Stark（工程韧性导向）
“临时 ClientSession 不关？这在高频调用里就是定时炸弹。连接池、句柄、告警全会找上门。把会话生命周期设计成‘单一入口、可控关闭’，系统会安静很多。”

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[aliveriver]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_listen_github

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. 初始化失败时会误推“历史消息”（功能正确性，较严重）
   你在 _poll_loop 里先 await self._init_cursors() 再 await self._do_poll()，但 _do_poll() 没有检查某个目标是否已成功初始化。
   这会导致一种情况：

   • _init_cursors() 因网络抖动未能写入游标；
   • 同一轮 _do_poll() 恰好拉取成功；
   • last_entry_id 为空，于是把历史内容当“新动态”推送。
     这与注释里“失败时保留未初始化状态以便下次重试、避免首次历史推送”的目标冲突。

2. max_entries > 0 时存在“消息丢失”风险（功能正确性，较严重）
   _fetch_new_entries() 会先收集到 new_entries，再截断 new_entries[:self.max_entries]，最后把游标写成 new_entries[0]["id"]（最新的一条）。
   如果实际新增很多条（比如 30 条），max_entries=5，这轮只推 5 条且游标直接跳到最前，剩下 25 条将永远不会再被推送。

3. 并发写配置存在竞态（潜在缺陷）
   gh_bindhere / gh_unbindhere 直接原地修改 self.cfg_bound_sessions 并 save_config()，没有任何互斥。
   在异步环境下若两个管理指令几乎同时触发，可能出现“最后一次写覆盖前一次写”的情况，导致绑定列表丢更新。

4. 输入校验不足，gh_check 可产生大量无效外部请求（安全/稳健性）
   gh_check 直接把用户输入拼到 GitHub URL 路径，不校验用户名/repo 格式。
   虽然域名固定，不是典型 SSRF，但会导致：

   • 非法输入触发大量无效请求和错误日志；
   • 可能被恶意刷命令放大外部请求压力。
     建议最少加正则白名单（如 ^[A-Za-z0-9_.-]+(/[A-Za-z0-9_.-]+)?$）。

5. 前向兼容性风险：继续使用 @register（框架适配）
   根据你给的规范，v3.5.20+ 已废弃 @register。当前代码仍依赖它，若部署环境升级且清理旧兼容逻辑，存在加载行为变化风险。

---

代码评审团

人物一：Linus Torvalds（直球工程派）
“你这初始化逻辑写了注释说不推历史，结果网络一抖就全推了——注释和代码打架是最糟糕的 bug 类型。先让状态机正确，再谈优雅。”
建议：把“是否允许进入 _do_poll”与“各目标初始化完成状态”强绑定。

人物二：Steve Jobs（产品体验派）
“用户只会记住一件事：为什么我少收了很多条更新。max_entries 不该以丢消息为代价。”
建议：游标应推进到“本轮已处理的最旧一条”或引入补偿拉取机制，保证消息可追溯。

人物三：Tony Stark（高并发实战派）
“异步里改共享列表还直接落盘？这在高并发场景里就是等着互踩。能跑不代表能扛。”
建议：给绑定列表更新加原子化保护（如 asyncio.Lock），并统一封装配置读写路径。

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[aliveriver]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_listen_github

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

1. 增量游标更新逻辑会导致消息丢失（功能正确性，高优先级）
   在 _fetch_new_entries 中，先收集到所有新条目，再按 max_entries 截断，最后把游标更新为 new_entries[0]["id"]（最新一条）。

   • 当“新动态数量 > max_entries”时，未发送的较旧新动态会被永久跳过。
   • 例：新动态有 10 条，max_entries=3，只发 3 条，但游标直接跳到最新，剩余 7 条下次不会再发。

2. 扫描窗口上限也会造成漏推（功能正确性，中高优先级）
   scan_limit 受 MAX_SCAN_ENTRIES / max_entries*2 限制。若上次游标对应条目不在扫描窗口内（例如积压很多），代码会只看前 scan_limit 条并更新游标，窗口之外的更新会被永久跳过。

3. 并发发送时复用同一个 MessageChain 实例（潜在并发缺陷，中优先级）
   _do_poll 中一个 chain 被多个 _safe_send 并发复用。如果底层发送实现会修改 MessageChain（常见于序列化、补元数据等），可能引发竞态或串扰。建议每次发送创建独立 MessageChain。

4. gh_check 在 max_entries=0 时可能输出过大（可用性/性能，中优先级）
   gh_check 里 max_entries=0 会遍历 feed.entries 全量输出，容易产生超长消息、触发平台长度限制或导致发送失败。建议为手动检查命令设置单独硬上限。

5. 轮询读取与配置写入缺少一致性保护（潜在缺陷，低优先级）
   gh_bindhere/gh_unbindhere 用 _config_lock 修改配置，但 _do_poll 无锁读取列表；极端情况下可能出现“本轮发送目标不一致”或迭代期间变更导致的非预期行为。

6. @register 在新版本框架中属于兼容性风险点（维护性，低优先级）
   代码使用了 @register，在你给的规则中注明 v3.5.20 之后该装饰器已废弃（虽可工作于旧行为）。建议预留无 @register 的兼容写法，降低未来迁移成本。

代码评审团

人物一：Linus Torvalds（直球毒舌版）
“你这个游标更新逻辑太‘自信’了：只发 3 条却把游标推到最新，等于告诉系统‘其余都看过了’。这不是增量同步，这是增量失忆。先保证不丢数据，再谈优雅。”

人物二：Steve Jobs（产品体验执念版）
“gh_check 全量吐消息在工程上能跑，但在产品体验上很糟：用户看到一堵文本墙。你需要‘有节制的信息设计’——默认展示少量、可分页、可继续拉取。”

人物三：Tony Stark（工程炫技现实派）
“并发发送复用同一个消息对象？听起来像‘应该没事’，而这正是线上事故最爱的开场白。给每个会话独立构建消息体，成本低、收益高、能少熬夜。”

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[astrbot-plugin-copybara]

插件信息已同步到集合仓库。
PR: AstrBotDevs/AstrBot_Plugins_Collection#298
已自动合并 PR #298

该插件已上架。
This plugin is now published.