5 Commits

Author	SHA1	Message	Date
JianFeeeee	61f402beef	fix(lua): 定时任务改跑在插件自己的 VM 上 —— 纠正 Phase 4 的双 VM 错误 ... 用户指出的设计错误：**一个插件 = 一个 Lua VM = 一个调度器**。而 Phase 4 （4d1407b）给定时任务开了一个**私有 VM**，于是： 定时任务 refresh_token 写 plugin.state.token → 写进私有 VM 的副本 请求钩子 读 plugin.state.token → 读主 VM 的值 轮换"成功"了，对实际流量完全无效；而且私有 VM 绕过状态持久化，token 连 磁盘都到不了。这直接违背这个功能存在的理由。 ## 修正 PluginRuntime 不再持有 Lua 状态。任务通过 p.state + p.mu 运行 —— 与请求 钩子**同一个 VM、同一把锁**： - 任务写入立即可见于钩子（TestTaskWriteIsVisibleToHooks 锁死这一点） - 任务写入经 markDirtyLocked 走同一套持久化 - 跨插件仍并行（每插件各自 VM、各自锁） ## 由此产生的行为（有意为之，非缺陷） - 某插件的长任务会排在**它自己**的钩子前面（同一 Lua 栈，一次一个调用者） - 卡死处置随之改变：不再"抛弃 VM 重建"（那会丢掉累计状态——计费总额、 签到历史，正是插件存在的意义），而是**停用该插件**： - checkWedged 超过 wedgedAfter(10min) 置 disarmed - Fire 对 disarmed 插件快速失败并记 hook_errors（否则请求会排在永不释放 的锁后面永久挂起——比停用更糟） - Unload 检测 InFlight：有任务在跑时不取 p.mu（会永久挂起）、不 Close 状态（Lua C 层 use-after-free 直接 abort）。泄漏这一个状态是有界的， 比崩溃好。 - maxAbandons/抛弃计数因此删除：没有"重生"了，熔断由 disarmed 承担 ## 测试（10 个） 主断言从"任务跑过"改为"**任务的写入对请求路径可见**"—— 旧实现会在这里 失败。另含：无触发自执行/无 schedule 无运行时/解析/at 下次触发/错误隔离/ 卸载停 goroutine/卡死停用+钩子快失败/健康任务不误判/8 插件并发各自调度。	2026-10-11 12:59:36 +08:00
JianFeeeee	57fada3b0d	docs(lua): 更正 ScheduledTask.Timeout 注释 —— 超时由抛弃 generation 实现，非 Lua 指令级中断	2026-10-11 12:14:49 +08:00
JianFeeeee	b6148e6f79	chore(lua): 删除调度器里两个无人调用的诊断辅助函数 ... sortedTaskNames / PluginTasks 是开发 Phase 4 时留下的诊断辅助，最终 没有任何调用点（WebUI 走 /api/plugins 的既有结构）。连同不再需要的 sort import 一并删除，保持包面干净。	2026-10-11 11:41:08 +08:00
JianFeeeee	9016eda905	feat(lua): 卡死任务改为「抛弃整个 VM」—— 不中断，直接换一代 ... 用户给的架构决策：与其想尽办法中断卡死的插件任务，不如直接抛弃它所在的 VM，让任务的 goroutine 跟 VM 一起被处置。这比中断干净 —— VM 重建只要 ~0.1ms，抛弃比修复便宜。 ## 为什么必须这样做（三次实测） 本 golua + LuaJIT 构建**无法中断**运行中的 Lua 调用： 1. SetExecutionLimit(200000) 对紧密循环 10s 未返回 —— 无效 2. 计数 hook(2000) + RaiseError 对紧密循环 fired=0 —— hook 未触发 3. 计数 hook(1000) 对「函数调用+表写」循环 fired=20971 触发， 但 RaiseError 后仍未返回 —— RaiseError 走 L.StackTrace()， 正是 vm.go 已记录的 SIGSEGV / 无法跨 C 栈路径 原因：LuaJIT 把紧密循环编译成机器码，指令计数 hook 只在解释器路径触发； 而唯一能在 C 栈上中断的 golua 入口恰好依赖 StackTrace()。 ## 模型：generation 可抛弃 PluginRuntime 持有一个 runtimeGen（私有 VM + 单状态池）。任务超过 wedgedAfter（10min，因为正常情况就是慢网络调用）仍不返回时： - 抛弃该 generation，由 ensureGeneration 在下一 tick 起一个干净的 - 卡死的 goroutine 留在旧 VM 上，永远碰不到新一代的状态 - 在飞任务被 carry 到新 generation 并重新排期（否则 abandon 计数永不前进， 熔断也就永远不触发） ## 熔断（必须有） 每次抛弃都留下一个永不返回的 goroutine + Lua 状态。没有上限的话，一个 必然卡死的任务会让运行时每 10 分钟建一个新 VM —— 由插件自身 bug 驱动的 无界泄漏。maxAbandons=5 后熔断停止重生，需人工 reload（同 systemd 单元 反复启动失败后的姿态）。 ## 开发中修掉的四个缺陷 1. rt.gen 未赋值：bootGeneration 的结果只赋给局部变量，导致 checkWedged/ runDue/dropGeneration 全部读到 nil，运行时会「活着但一个任务都不跑」。 2. checkWedged 无条件抛弃：即使没有任何任务判定为 wedged 也 drop， 让健康插件不断换代。 3. startedAt 由 runDue 设置而非 runOne：任何其它 dispatch 路径的任务 都不会被追踪，checkWedged 无法区分「在跑」与「从未启动」。 4. runOne 收到 nil gen 会 panic（抛弃与派发竞争）—— 改为安全返回并清标志。 测试：13 个（无触发自动执行/真正执行/零开销/at 解析/条目校验/失败隔离/ 卸载停 goroutine/压力/抛弃换代/熔断/健康任务不受影响）。	2026-10-11 10:40:58 +08:00
JianFeeeee	4d1407bbb4	feat(lua): 插件长期运行环境（R4-b）—— 内核驱动调度 + 独立 VM ... 用户需求：插件需要长期运行环境（独立 LuaVM 线程化），以支持自动签到、 token 轮换这类"没有浏览器、没有人操作时也要发生"的能力。 旧模型做不到：插件的周期工作只能靠前端 pluginAPI.call 驱动，页面没开就 一次都不跑。这正是自动签到的死穴。 新增 internal/lua/plugin_runtime.go：插件声明，内核驱动。 PLUGIN.schedule = { { fn = "refresh_token", every = 3600 }, { fn = "daily_checkin", at = "03:30" }, { fn = "poll_quota", every = 300, jitter = 30 }, } - 每个声明了 schedule 的插件获得**私有 VM**（不是共享 plugin.state 的那个： 钩子要累加，任务要长跑且网络阻塞，两者对隔离的要求相反） - 内核单个 ticker 驱动所有任务；每个任务**独立 goroutine**，一个长任务 不推迟另一个的 due - `at="HH:MM"` 每日固定时刻；`jitter` 打散首触发，避免整点齐射 - 任务失败计数进入 hook_errors 面（静默坏任务必须可见） - Unload 先停调度再关状态（顺序反了会让在跑的任务写进已关闭的 Lua 状态） 明确边界：**适配器不参与调度**。适配器仍是无状态请求级池；token 轮换靠 插件（这里）按周期调用 Phase 3 的 UpdateAdapter。 修掉两个把进程直接搞崩的缺陷： 1. 私有 VM 的池我给 sync.Cond 传了新 mutex 而非池自己的 mu → "unlock of unlocked mutex"，fatal error 而非可恢复错误。 2. Transform 硬编码 adapterGlobal，而插件模式的池把表存在 pluginGlobal → 健康的状态也报 "has no table"。加 poolGlobal(p) 按模式选择。 测试 8 个：无任何触发自动执行（核心）/真正执行了（计数读回）/无声明则零开销/ at 解析与畸形退化/不完整条目被忽略/失败隔离/卸载停 goroutine/6 插件×3 任务压力。	2026-10-11 10:26:39 +08:00