Skip to content

Conversation

@L-aros
Copy link

@L-aros L-aros commented Dec 20, 2025

📜 标题(Title)

请提供这个Pull Request中提议的更改的简洁描述:

  • Update app/messages/message_pusher.py:统一消息推送流程,新增飞书通道与通知历史记录。

🔍 描述(Description)

请描述这个PR做了什么/为什么这些更改是必要的:

  • 封装统一的消息推送入口 MessagePusher.push_messages,集中调用钉钉、企业微信、Bark、ntfy、Telegram、飞书、邮件、ServerChan 等通道,避免调用散落在各处,便于后续维护。
  • 新增 is_any_push_channel_enabledshould_push_message 等判定逻辑,用于根据用户配置和当前录制状态(开播/下播、是否仅通知不录制、是否手动停止)决定是否发送通知,减少无效推送。
  • 集成飞书推送通道:
    • SettingsPage.user_config 中读取 feishu_enabledfeishu_webhook_urlfeishu_msg_typefeishu_sign_secret 等配置;
    • 调用 NotificationService.send_to_feishu 完成签名、时间戳和消息体组装,并记录成功/失败日志。
  • 新增通知历史记录功能 _append_notification_history
    • 按时间倒序记录每次推送的标题、内容、类型(start/end)、元信息(meta)、各通道结果等;
    • notification_history_enablednotification_history_max_entries 配置控制,自动截断超出最大条数的历史;
    • 写回 user_config 并通过 config_manager.save_user_config 持久化,便于在设置界面查看历史记录。
  • 增强日志输出:
    • 通过 log_push_result 对每个通道统一记录成功或失败,其中失败会带上错误列表,便于排查推送异常。

这些改动是必要的,因为:

  • 统一的推送入口可以避免重复逻辑和遗漏通道;
  • 推送条件判断更精细,可以减少用户不希望看到的“噪音通知”;
  • 通知历史记录便于用户事后核对“什么时候推送过什么内容”,提高可观测性;
  • 飞书通道是新的需求,必须接入统一推送体系中。

📝 类型(Type of Change)

这个PR引入了哪种类型的更改?(请勾选所有适用的选项)

  • 修复Bug
  • 新功能
  • 代码风格更新(格式化,局部变量)
  • 重构(改进代码结构)
  • 构建相关更改(依赖项,构建脚本等)
  • 其他:请描述

说明:

  • Bugfix:修正了原先“是否需要推送”的判断不充分的问题(例如未统一检查所有通道开关、未区分手动停止导致的下播不应推送等)。
  • Feature:新增飞书推送通道与通知历史记录功能。
  • Refactoring:将推送逻辑集中到 MessagePusher 中,简化其他模块调用。

🏗️ 测试(Testing)

请描述您已经进行的测试:

  • 本地开发环境(Windows 11 + Python 3.11)运行 python main.py,确保应用可正常启动。
  • 添加一条抖音录制任务,开启“开播通知”和“下播通知”,分别触发:
    • 开播时:
      • 确认各开启的推送通道(如钉钉、企业微信、飞书等)能收到消息或在日志中看到对应推送结果;
      • 检查 MessagePusher.should_push_message 对开播场景返回 True
    • 下播时:
      • 在配置允许推送下播通知的前提下,确认通道被调用且历史记录中有新增一条“end”类型记录;
      • 当录制被手动停止且开启了“手动停止不推送”逻辑时,验证不会发送下播通知。
  • 记录几次推送后,确认 notification_history 中条目数不会超过配置的 notification_history_max_entries,旧记录被正确截断。

如果适用,请提供测试更改的说明:

  • 在“设置”中:
    1. 配置并开启至少一个消息通道(例如飞书 / 钉钉);
    2. 打开“开播通知”和“下播通知”;
    3. 视需求开启“通知历史记录”,并设置一个较小的最大条数(例如 5)。
  • 添加一个直播任务并开启录制:
    1. 直播开始时观察各推送通道是否收到开播消息;
    2. 直播结束或手动停止录制后,观察下播消息是否符合预期(特别是“手动停止不推送”场景);
    3. 在通知历史 UI 中查看记录列表是否按时间倒序展示,并且不会超过最大条数。

📋 检查清单(Checklist)

在您创建这个PR之前,请确保以下所有框都被勾选,方法是在每个框中放置一个x

  • 我已经阅读了贡献指南文档
  • 我的更改没有产生新的警告
  • 我已经添加了覆盖我更改的测试
  • 我已经相应地更新了文档(如果适用)
  • 我遵循了这个项目的代码风格

注意: 这个PR在所有复选框被勾选之前不会被合并。


感谢您的贡献!

  - 统一封装多渠道推送逻辑,新增对飞书渠道的调用与错误日志输出。
  - 新增是否需要推送的判定逻辑(区分开播/下播、仅通知不录制、手动停止等场景)。
  - 新增通知历史记录写入逻辑,将每次推送结果(时间、标题、内容、元信息、各渠道成功/失败)持久化到用户配置中。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant