43 lines
3.1 KiB
Markdown
43 lines
3.1 KiB
Markdown
# 背景
|
||
文件名：2025-11-08_1_register-clock-trigger.md
|
||
创建于：2025-11-08_00:38:54
|
||
创建者：ASUS
|
||
主分支：main
|
||
任务分支：未创建
|
||
Yolo模式：Off
|
||
# 任务描述
|
||
插件框架需要支持在插件执行阶段注册并定期触发的clock回调。
|
||
# 项目概览
|
||
当前架构通过Architecture.Register管理插件生命周期，但缺少可用的定时调度机制。必须分析如何安全地触发插件提供的clock回调。
|
||
# 分析
|
||
目前 `PluginInterface.execute` 在 `Architecture.Register` 中仅绑定 `wake_up`，插件自行决定何时启动定时任务；原先取得 `register_clock()` 的逻辑已移除。
|
||
框架缺乏任何定时任务持久化结构，需要扩展 `Database` 或新增表来保存待执行任务及其计划执行时间。
|
||
调度接口需要符合 `register_clock(callback, time)` 一次性延时调用模型，回调若要持续执行需自行再次注册。
|
||
任务触发误差需从 `ProjectConfig` 读取配置，服务器重启后所有已到期任务应立即执行，未到期任务需按剩余时间继续等待。
|
||
时间单位为毫秒，每个插件可以同时注册多个延时任务，不设并发限制，需确保调度层能最大限度向插件开放自由度。
|
||
延时任务执行必须由独立的事件循环系统负责，插件实例不应自行保存或执行任务；事件循环应按配置误差间隔检查到期任务，并在执行任务时支持回调中继续注册新任务而不引发并发竞态。
|
||
# 提议的解决方案
|
||
- 扩展数据库，在 `scheduled_tasks` 表中保存任务ID、回调标识、序列化参数、执行时间（毫秒时间戳）和状态，确保重启后恢复。
|
||
- 新增 `ClockScheduler` 模块，独立读取数据库、按配置误差间隔扫描到期任务并执行，执行前后更新任务状态并记录结果。
|
||
- 在 `PluginInterface` 中实现 `register_clock`，将插件提供的回调标识与延迟毫秒数交给调度器；插件可传递payload以便执行时还原上下文。
|
||
- 在 FastAPI 应用启动时创建并启动调度器后台任务，停止时优雅关闭；从 `ProjectConfig` 读取调度周期等配置。
|
||
- 设计回调解析器，通过模块/类/函数标识和payload反射执行回调；允许回调内部再次注册延时任务而不影响调度循环。
|
||
# 当前执行步骤："1. 创建任务文件"
|
||
# 任务进度
|
||
2025-11-08_01:14:21
|
||
- 已修改：PWF/CoreModules/database.py PWF/CoreModules/clock_scheduler.py PWF/CoreModules/plugin_interface.py PWF/Application/web.py PWF/Convention/Runtime/GlobalConfig.py
|
||
- 更改：创建持久化延时任务表与CRUD接口；实现独立调度器并集成FastAPI生命周期；为插件提供register_clock封装；配置默认调度参数。
|
||
- 原因：满足延时任务持久化与独立事件循环需求，支持重启恢复。
|
||
- 阻碍因素：无
|
||
- 状态：未确认
|
||
|
||
2025-11-08_01:22:21
|
||
- 已修改：PWF/Convention/Runtime/GlobalConfig.py
|
||
- 更改：撤回 scheduler 默认配置写入，保持 ProjectConfig 原始行为。
|
||
- 原因：遵循架构约束，避免上游配置被功能耦合。
|
||
- 阻碍因素：无
|
||
- 状态：未确认
|
||
|
||
# 最终审查
|
||
待补充
|