[Plugin] astrbot_plugin_steammod_monitor

[danfong1104]

插件信息

{
"name": "astrbot_plugin_steammod_monitor",
"display_name": "steam创意工坊检测/服主开服工具",
"desc": "用于监控steam的创意工坊和mod状态变更，并在状态变化时推送通知。硬核游戏服主（僵尸毁灭工程、方舟、Rust等）打造的“赛博网监”级 AstrBot 插件。 彻底告别“玩家进不去服务器才发现模组更新”的窘境，实现全自动更新预警与优雅的群组推送和管理！",
"author": "danfong1104",
"repo": "https://github.com/danfong1104/astrbot_plugin_steammod_monitor",
"tags": [
"steam"
]
}

插件检查清单

• 我的插件经过完整的测试
• 我的插件不包含恶意代码
• 我已阅读并同意遵守该项目的 行为准则。
  [+][/+][+]
• 重新提交审核

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_steammod_monitor

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

main.py

以下仅列出发现的问题（基于 Python 3.10 + 异步运行环境）：

1) 功能逻辑与正确性问题

1. RCON 协议实现不完整，存在误判风险
   AsyncRCON 里 _read() 只读取单个响应包，connect() 也只检查一次 id == -1。
   Source RCON 常见场景会返回多个包（尤其认证/长响应），当前实现可能导致：

   • 认证状态误判；
   • execute() 响应截断（只拿到第一包内容）。

2. RCON packet_id 固定为 1，缺少请求-响应关联机制
   _send() 每次都写死 packet_id = 1，在并发或多响应场景下难以保证返回包匹配正确请求，增加解析错误概率。

3. 玩家数查询失败时逻辑“静默卡住”
   get_online_players() 异常返回 -1，但 handle_auto_restart_logic() 只处理 ==0 和 >0，-1 分支无告警、无兜底动作，可能导致“有待更新但永远不推进”。

4. 配置类型未做严格校验，任务可能在运行时崩溃
   如 poll_interval_minutes、max_retries、server_port、倒计时等来自配置，若是字符串或非法值，会在 asyncio.sleep / 网络调用处抛错，后台任务可能直接退出。

5. poll_interval_minutes 缺乏下限保护
   配置成 0 或负数会导致轮询异常（高频循环或直接异常），影响稳定性。

---

2) 并发与任务管理问题

1. 在 __init__ 中全局扫描并取消同名任务，影响面过大
   asyncio.all_tasks() + 任务名匹配取消，会波及同进程中“恰好同名”的其他任务。且取消后未 await 回收，可能出现悬挂取消状态。

2. 缺少“重启任务去重”机制
   手动 /steammod restart 可被重复触发，多次创建 execute_rcon_restart()，可能并发发出多组 save/quit 指令。

3. 共享状态无一致性保护
   pending_updates、is_restarting、broadcast_sent_for_current_updates 被多个协程读写（监控循环、手动命令、健康检查），可能产生时序竞争，导致重复广播或状态错乱。

---

3) 可维护性与可读性问题

1. 职责过于集中（God Class）
   SteamModMonitor 同时承担：配置解析、Steam API 调用、RCON 客户端协调、消息发送、调度、状态机，类体过长且耦合高，后续维护成本高。

2. 大量魔法值散落
   如固定 sleep(5), sleep(180), sleep(20) 等，缺少统一常量定义，调优困难且易引发行为不一致。

3. 未使用导入
   json 未被使用，增加噪音。

---

4) 安全与稳健性问题

1. 异常日志直接输出 repr(e)，可能泄漏敏感上下文
   某些网络/连接异常对象可能携带连接细节（地址、认证上下文），建议脱敏后记录。

2. send_alert 强依赖先“捕获 bot 实例”
   若未先执行过 /steammod，关键告警无法主动推送（只记日志不通知），属于高可用性风险。

---

5) 框架适配专项检查（main.py）

1. @register 在新版本中已废弃，存在后续兼容心智负担
   你当前写法语法上可用，但若团队已迁移到 v3.5.20+ 推荐范式，继续使用装饰器会造成“新旧加载机制混用”的维护风险。

2. 数据持久化缺失（状态全内存）
   last_update_times / pending_updates / last_reset_date 重启即丢失。
   这类状态若用于“避免重复告警/识别更新增量”，应落盘到插件数据目录（StarTools.get_data_dir()），否则会出现重启后重复告警或漏判基线问题。

---

代码评审团

人物一：Linus Torvalds
“你这异步框架跑得挺勤快，但 RCON 协议处理太‘想当然’了：单包读取 + 固定 packet id，这不是工程化，这是赌运气。建议先把协议状态机做正确，再谈自动化重启。”

人物二：Steve Jobs
“功能很多，但产品体验上有一个致命点：关键告警依赖用户先手动触发一次命令才能拿到 bot 实例。真正的‘自动化’不应该要求用户先做仪式。把这条链路做成开箱即用。”

人物三：Geralt（利维亚的杰洛特，虚构角色）
“我见过不少怪物，‘并发状态错乱’是最阴的那种。pending_updates、is_restarting 到处改，没个锁或统一状态流，迟早会在深夜给你来一刀。先定规则，再动手。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[danfong1104]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_steammod_monitor

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

main.py

1. 后台任务生命周期管理不完整，存在“幽灵任务”风险

   • terminate() 只取消了 self.monitor_task 和 self.reset_task，但代码中还通过 asyncio.create_task() 动态创建了多个未被追踪的任务：
     • execute_rcon_restart()
     • verify_server_health()
   • 这些任务在插件终止后仍可能继续运行，导致：
     • 插件卸载/重载后仍继续发消息或探针检测
     • 状态被旧任务继续修改
     • 难以排查的并发行为
   • 建议：统一维护任务集合，创建任务时登记，terminate() 中集中取消并 await 回收。

2. terminate() 取消任务后未等待结束，优雅退出不完整

   • 当前逻辑只是 task.cancel()，没有 await task 或 asyncio.gather(..., return_exceptions=True)。
   • 这会导致：
     • 任务中的 finally/清理逻辑未必执行完成
     • 可能出现 “Task was destroyed but it is pending” 一类问题
   • 在异步环境里，这属于典型的任务回收不彻底问题。

3. 插件初始未运行时，后续 steammod on 不能真正启动后台轮询

   • monitor_task 和 reset_task 只在 __init__ 中、且 self.is_running 初始为真时才创建。
   • 如果启动时因为配置不完整或人为关闭导致未创建任务，后续执行 steammod on 只是把 self.is_running = True，并不会补建后台任务。
   • 结果是：
     • 手动命令会执行一次检查
     • 但不会进入持续轮询/定时逻辑
   • 这是明显的功能逻辑缺陷。

4. AsyncRCON.execute() 对多包响应处理不正确，长响应可能被截断

   • 当前逻辑在读到第一个 id == req_id 的包后立即 break。
   • Source RCON 的响应可能分多包返回，尤其在响应较长时很常见。
   • 这会导致：
     • players、广播结果或其他命令输出被截断
     • 上层逻辑误判，例如在线人数解析失败
   • 这是协议实现层面的正确性问题。

5. AsyncRCON.execute() 超时后直接吞掉异常并返回部分/空结果，容易掩盖真实失败

   • except asyncio.TimeoutError: pass 会让调用方收到一个“看起来合法但实际不完整”的字符串。
   • 这会造成：
     • 网络抖动、协议异常被误认为“空响应”
     • 上层逻辑把错误状态当成业务状态处理
   • 更稳妥的做法是区分“确实无输出”和“超时/异常”。

6. RCON 连接异常时资源释放不够稳妥

   • AsyncRCON.connect() 在认证失败或 _read() 异常时直接抛出，但没有确保连接被关闭。
   • 如果认证失败或半连接异常出现，可能遗留未关闭的 socket/stream。
   • 尤其在轮询式插件中，长时间运行会放大这类资源泄漏风险。

7. 自动重启逻辑存在并发竞态，可能重复进入处理流程

   • process_result() 在锁内计算 needs_restart = bool(self.pending_updates) and not self.is_restarting，然后释放锁后调用 handle_auto_restart_logic()。
   • 如果有两个并发检查同时通过这段逻辑，它们都可能在锁外继续执行自动处理。
   • 可能后果：
     • 重复广播
     • 重复发送群消息
     • 重复触发重启流程
   • 这属于典型的“检查-执行分离”竞态。

8. 群通知与实际游戏内广播状态不一致，可能误导用户

   • handle_auto_restart_logic() 在 players_count > 0 分支中，先向群发送：
     • “已向游戏内发送广播预警”
   • 但真正的 RCON 广播是在后面才执行；如果 rcon.connect() 或 execute() 失败，群里会收到错误的成功描述。
   • 这属于业务语义错误，建议先执行广播成功后再发“已广播”的通知，或者将文案改为“尝试发送广播”。

9. HTTP 非 200 响应在重试耗尽后没有最终错误日志，排障困难

   • check_steam_updates_with_retry() 中，response.status != 200 时只是 sleep 然后继续重试。
   • 如果所有尝试都返回非 200，函数会静默结束，没有最终失败日志。
   • 这会导致：
     • 看起来插件“没报错但也没工作”
     • 生产环境排障非常困难
   • 至少应在最后一次失败时记录状态码和请求目标。

10. 在线人数解析依赖单一正则，失败时会误判为 0 人在线

    • get_online_players() 使用：

      re.search(r'Players connected \((\d+)\)', resp)

• 如果服务端输出格式稍有变化、被截断、语言不同、或 RCON 返回不完整，就会落入 return 0。
• 误判为 0 人在线的后果非常严重：可能在实际上有人在线时自动重启服务器。
• 更合理的是：
  • 解析失败时返回 -1
  • 让上层走“保护服务器，不自动处理”的分支

11. 健康检查与 RCON 共用同一个 server_port，配置语义容易混淆

    • 当前 server_port 同时用于：
      • AsyncRCON(self.server_ip, self.server_port, ...)
      • tcp_ping(self.server_ip, self.server_port)
    • 但很多服务端场景中，游戏端口与 RCON 端口并不相同。
    • 这会导致：
      • 连接的是错误端口
      • 健康检查“在线”并不代表游戏服可用
      • RCON 连不上时误以为服务器离线，或反之
    • 建议明确拆分 game_port 和 rcon_port。

12. auto_reset_loop() 的行为命名与实现不一致，容易误导维护者

    • 从名字看像“定时重置/重启”，但实际逻辑是：
      • 触发健康检查，或
      • 清空 pending_updates
    • 这会让代码阅读者误解功能边界，增加维护成本。
    • 尤其“清空待更新状态”本身是高风险操作，如果名字不准确，后续维护很容易误改。

13. manual_status_check() 与自动轮询查询逻辑重复，后续维护容易出现行为分叉

    • Steam API 请求构造、超时配置、返回结构处理在多个函数中重复出现：
      • manual_status_check()
      • check_steam_updates_with_retry()
    • 当前已经出现“手动查询展示逻辑”和“自动处理逻辑”割裂的问题。
    • 一旦接口字段变化，容易漏改其中一处，产生不一致行为。

14. 存在未使用导入，影响可读性

    • import os 未被使用。
    • 在审查尺度上这属于小问题，但说明文件已经有轻微的“残留代码”倾向。

---

代码评审团

人物一：Linus Torvalds

这段代码最大的问题不是“能不能跑”，而是“跑起来以后谁来收尸”。create_task() 到处飞，terminate() 却只管两个任务，这就是典型的异步系统失控前兆。建议你把任务管理做成一等公民，不要指望运气帮你清理协程。

人物二：Steve Jobs

你这里的用户体验问题很刺眼：群里先说“已经广播了”，结果实际上广播可能失败。软件不仅要工作，还要说真话。通知文案和真实执行顺序必须一致，这种细节决定了一个工具看起来像产品，还是像脚本拼装件。

人物三：Ken Thompson

协议处理要朴素、准确。RCON 响应可能分包，你却读到第一个包就收工，这种实现方式很容易在边界条件下自我欺骗。网络程序最怕“看似正常”，因为那会把错误静悄悄地传到业务层。先把协议读完整，再谈上层逻辑。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[danfong1104]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_steammod_monitor

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

main.py

1. [高] RCON 响应读取逻辑可能截断结果，导致功能不正确

   • AsyncRCON.execute() 在读取到首个 id == req_id 的包后就 break，但 Source RCON 可能返回多包响应。
   • 这会导致：
     • 返回内容不完整；
     • 残留包污染下一次命令读取，产生“串包/错包”风险。

2. [高] execute() 超时后静默吞掉异常，可能掩盖协议错误并造成状态失步

   • except asyncio.TimeoutError: pass 直接返回部分结果或空结果，没有日志、没有重试、没有连接重建。
   • 在长响应、网络抖动或服务端延迟时，会出现“看似成功但实际未完整执行”的隐蔽故障。

3. [高] 在线玩家数解析失败时默认返回 0，可能误触发自动重启

   • get_online_players() 中如果 players 命令响应格式变化，正则未命中即 return 0。
   • 0 被业务逻辑解释为“无人在线”，会直接走自动重启路径，存在误伤在线玩家的风险。

4. [中] 多处异常被吞掉/弱化，降低可观测性和可维护性

   • _save_data() 异常直接 pass；
   • get_online_players() 捕获异常后直接 -1，无详细日志；
   • check_steam_updates_with_retry() 在连续非 200 状态码失败时无最终错误日志。
   • 结果是线上问题难定位，恢复依赖人工猜测。

5. [中] steammod on 仅置位 is_running=True，未确保后台任务存在

   • 若初始化时因配置不足未启动任务，后续执行 on 并不会补建 monitor_task / reset_task。
   • 表面“已开启”，实际不会自动轮询，存在功能一致性问题。

6. [低] 存在未使用导入，影响代码整洁度

   • import os 未使用，属于可清理项（代码规范/可读性问题）。

7. [低] @register 在新框架版本中已废弃，存在未来兼容维护成本

   • 当前写法可运行，但会增加后续迁移/告警处理负担（非立即功能性错误）。

---

代码评审团

人物一：Linus Torvalds（务实暴躁流）
“你这个 RCON execute 读一包就跑，典型‘在我电脑上能跑’写法。协议是协议，不是玄学。把多包响应处理完整，再谈可靠性。否则线上就是随机炸。”

人物二：Steve Jobs（产品体验流）
“用户收到‘已重启成功’这类消息时，背后逻辑必须绝对可信。你现在把异常吞掉、状态模糊化，体验上是‘看起来很优雅’，工程上却是‘不确定性很高’。可观测性就是体验的一部分。”

人物三：Tony Stark（工程极客流）
“自动化很酷，但 players 解析失败就当 0 人，等于给重启按钮接了个概率触发器。建议把‘未知状态’当危险态处理，宁可不自动重启，也别误重启。Jarvis 都不会这么赌。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[danfong1104]

不改了，就这样吧，请老大审批上架

[astrbot-plugin-copybara]

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

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