[Bug] L2_schedule timer 错误映射为 offload-l2，导致 L2/L3 记忆从未生成

[henghengairourou]

OpenClaw Version | OpenClaw 版本

N/A（插件独立运行，未通过 OpenClaw）

Plugin Version | 插件版本

@tencentdb-agent-memory/memory-tencentdb 1.0.0

Operating System | 操作系统

macOS26.5.1

System Specification | 系统配置

No response

Describe the bug | 问题描述

问题描述

src/gateway/server.ts 中 onTimerExpired 回调将 L2_schedule timer 的任务类型映射为 offload-l2（上下文压缩），而非 L2（记忆场景提取）。由于 cascadeSchedule() 只处理 task.type === "L2" 的任务，导致 L2 场景提取从未执行，L3 persona 生成也因级联中断而从未触发。

影响：L1 atom 记忆可以正常提取，但 L2 scenario 和 L3 persona 永远不会生成，四层记忆架构实际只有前两层在工作。

复现步骤

1. 正常安装并启动 Gateway（src/gateway/server.ts）
2. 通过 /capture API 发送 5+ 轮对话（满足 everyN=5 的 L1 触发条件）
3. 等待 L2 timer 触发（l2DelayAfterL1=10s，默认 l2MinInterval=900s）
4. 检查日志和输出文件

预期行为

• L2_schedule timer 触发后，应入队 L2 类型任务（记忆场景提取）
• L2 任务完成后，cascadeSchedule() 级联入队 L3 任务（persona 生成）
• scene_blocks/ 目录下生成场景文件
• persona.md 生成用户画像

实际行为

• L2_schedule timer 触发后，入队的是 offload-l2 类型任务（上下文压缩）
• offload-l2 任务在 1-16ms 内完成（仅执行调度检查，无实际记忆提取）
• cascadeSchedule() 不处理 offload-l2，级联中断
• scene_blocks/ 目录始终为空
• persona.md 从未生成
• checkpoint 中 scenes_processed 始终为 0

根因分析

问题代码

文件: src/gateway/server.ts，第 1173 行（onTimerExpired 回调内）

// 修改前（有 bug）
taskType = suffix === "L2_schedule" ? "offload-l2" : suffix === "L1_idle" ? "offload-l1" : "L3";


### To Reproduce | 复现步骤

1.正常安装并启动 Gateway（src/gateway/server.ts）
2.通过 /capture API 发送 5+ 轮对话（满足 everyN=5 的 L1 触发条件）
3.等待 L2 timer 触发（l2DelayAfterL1=10s，默认 l2MinInterval=900s）
4.检查日志和输出文件

### Expected behavior | 预期行为

L2_schedule timer 触发后，应入队 L2 类型任务（记忆场景提取）
L2 任务完成后，cascadeSchedule() 级联入队 L3 任务（persona 生成）
scene_blocks/ 目录下生成场景文件
persona.md 生成用户画像

### Error Logs / Screenshots | 报错日志/截图

_No response_

### Additional context | 补充信息

_No response_

[gugu23456789]

我们复现并确认了这个 bug，分享下根因分析和修复参考。

根因： src/gateway/server.ts:1173 的 onTimerExpired 回调中，旧格式定时器（sessionId:L2_schedule）的任务类型被映射为 "offload-l2"（上下文压缩），不是 "L2"（记忆场景提取）。PipelineWorker.executeTask() 按 task.type 路由：

• "L2" → executeL2()（场景提取 + cascadeSchedule() 触发 L3）
• "offload-l2" → executeOffloadL2()（MMD 画布更新，1-16ms 返回，无级联）

同样的映射错误也影响 L1_idle（变成 "offload-l1" 而非 "L1"）。

影响： L1 atom 可以正常提取，但 L2 场景和 L3 画像不会生成——四层记忆架构只有前两层在工作。

修复参考（两行）：

- taskType = suffix === "L2_schedule" ? "offload-l2" : suffix === "L1_idle" ? "offload-l1" : "L3";
+ taskType = suffix === "L2_schedule" ? "L2" : suffix === "L1_idle" ? "L1" : "L3";

验证： 我们写了个 31 项测试覆盖标准/边界/注入/幽灵攻击/管线全流程场景，全部通过。

测试和修复在 gugu23456789/TencentDB-Agent-Memory 的 r3-v1 分支（4b3ea00）。
测试日志：https://github.com/gugu23456789/tdai-adapter-evidence/blob/main/test_l2_timer-run.log

供官方参考，希望能有帮助。

[gugu23456789]

我们复现并确认了这个问题。它不是表面上的映射写错——实际上是三个 bug 连环，任意一个都足以让 L2/L3 管线断裂。

Bug ①：定时器映射错误（入口崩塌）

src/gateway/server.ts:1173 onTimerExpired 回调中，旧格式定时器键 sessionId:L2_schedule 的任务类型映射错误。原始代码：

// Bug: "L2_schedule" → "offload-l2"（MMD 画布更新，1-16ms 返回，无级联）
// Fix: "L2_schedule" → "L2"（场景提取 + cascadeSchedule 触发 L3）
taskType = suffix === "L2_schedule" ? "offload-l2" : suffix === "L1_idle" ? "offload-l1" : "L3";

"offload-l2" 走 executeOffloadL2()（第 1697 行），"L2" 才走 executeL2()（第 1550 行）。同样影响 L1_idle → "offload-l1" 而非 "L1"。

影响： L1 atom 可以正常提取，但 L2 场景和 L3 画像永远不会生成——四层管线只有前两层在工作。

Bug ②：StatefulPipelineManager 导入路径错误（启动崩塌）

src/gateway/server.ts:1283 动态导入 createStatefulPipelineManager 时从 pipeline-factory.js 导入：

const { StatefulPipelineManager } = await import("../utils/pipeline-factory.js");

但 pipeline-factory.js 导出的是 MemoryPipelineManager，它没有 advanceL2TimerAfterL1 和 armL2MaxInterval 方法——这两个核心定时器方法只在 StatefulPipelineManager 上。

修复：const { StatefulPipelineManager } = await import("../utils/stateful-pipeline-manager.js");

如果 Bug ① 被修复但 Bug ② 存在，Gateway 在 standalone 模式下启动时就会崩溃，根本到不了 L2 阶段。

Bug ③：集成测试用了 v2 API 路径和格式（验证崩塌）

我们最初写的验证脚本（a9a2bcd）用了 v2 的 API 路径和 body 格式：

路径错误 —— 使用了 v2 路径：

`${GATEWAY_URL}/api/v1/capture`   // v2 路径

而 v1.0.0 的实际路径是 /capture。

body 格式错误 —— 使用了 v2 body：

{"sessionId": "...", "instanceId": "...", "messages": [...]}  // v2 格式

而 v1.0.0 的 capture body 要求：

{"session_key": "...", "user_content": "...", "assistant_content": "..."}  // v1 格式

mock LLM 响应格式错误 —— 返回了：

{"memories": [{"text": "..."}], "scenes": [...]}  // 错误格式

而 L1 提取器（parseExtractionResult）期望的是 SceneSegment[] 数组，且记忆字段是 content 而非 text。

这意味着即使 Bug ① 和 Bug ② 都修了，集成测试也永远通不过（404 + 解析错误），无法验证修复有效性。

三个 Bug 的依赖链

Bug ① (映射错误) → L2 任务被路由到 offload-l2（死的）
Bug ② (导入错误) → Gateway 启动崩溃（即使映射对了也跑不到 L2）
Bug ③ (测试格式) → CI 测不出修复（即使①②都对了，验证也是假的）

只有三个全修了，L2 管线才真正可运行。

验证结果

• 31 项单元测试（scripts/repro-l2-timer-bug.ts）覆盖标准/边界/注入/幽灵攻击/管线全流程
• L2/L3 全管线集成测试（scripts/verify-l2-pipeline-mock.ts）用 mock LLM 验证了 capture → L1 提取 → L2 场景生成 → L3 persona 完整链路
• 3 平台 CI 全绿（Linux / macOS / Windows），含 Jaeger OTLP E2E

修复分支：gugu23456789/TencentDB-Agent-Memory 的 r3-v1（11b96b1）
CI 结果：https://github.com/gugu23456789/TencentDB-Agent-Memory/actions/runs/28919026006
测试日志：https://github.com/gugu23456789/tdai-adapter-evidence/blob/main/test_l2_timer-run.log

供官方参考。

[YOMXXX]

Triage update: #227 has been reviewed and approved as the local timer-routing fix. It routes legacy L2_schedule to L2 and L1_idle to L1, while keeping explicit offload-l2:* timers on the offload path. I verified src/gateway/timer-routing.test.ts locally; the remaining pnpm build failure is the known feat/server baseline dayjs dependency issue, not the timer-routing change.