事件日志与故障降级：坏了也不能崩，事后还能查

01问题引入：出事了，谁的锅？

前面的实验都在"一切正常"的前提下验证功能。真实部署会遇到：

02原理通俗讲解：黑匣子与各退一步

03关联知识点：五类事件 + 降级链

故障 → 收敛降级全链路（每条都有实验步骤对应）：

04实验目标

05实验环境与准备

实验前清空事件文件，否则旧记录会污染"新增事件"的判定：

cd ~/ros2_ws/src/xflz_eai_car1/app/object_tracking
> runs/logs/events.jsonl            # 清空便于判定新增（log.dir 可配置）
tail -f runs/logs/events.jsonl     # 另终端常开，实时观察追加

06动画讲解：故障注入与降级路径

图：四类故障各有绿色出口汇回主循环（绿框脉冲 = 持续存活），唯一的"离开"只往事件文件里写一行——绝不往 exit 写。

07互动讲解：故障注入沙盘

← 点击左侧任一故障/事件：观察降级路径、events.jsonl 新增行与副作用结论

九条路径覆盖 docs/09 的 E1-E3/E5/E6 与四类注入：fail 分支全部"不 submit"；断网后追踪/清除仍可用（规则兜底）、闲聊不可是设计预期；ReID/aplay/camera_stall 都是降级不退出。

08实操步骤：事件触发与故障注入

步骤 1-2 · 触发 lost / unlock_all 并核对：

cd ~/ros2_ws/src/xflz_eai_car1/app/object_tracking
python3 apps/track_app.py --video /home/iflytek/ros2_ws/src/xflz_eai_car1/vision/07_multi_object_tracking/test.mp4 --text --mjpeg
小飞小飞 → 追踪 id3 → 待目标出画 → 清除
# 另终端：
tail -f runs/logs/events.jsonl
{"t": ..., "kind": "command", "ids": [3], ...}       # 锁定留痕
{"t": ..., "kind": "lost", "ids": [3]}             # 差分 prev_ids-cur_ids，TTS"id3 已消失"
{"t": ..., "kind": "unlock_all", "ids": [3]}       # 全清才写；部分丢失不写

步骤 3 · fail-closed 用例（全程断言"不产生副作用"）：

追踪一百号目标 → track_ids 数值不对齐 {100} → [LLM] 未找到该 ID 目标   # E1：不锁、不走 VLM、不 grid dump
追踪蓝色皮卡（无蓝车）→ [track_vlm] 无法识别 → 回引导                # E2：_vlm_none，不锁
清除 → [track_app] 清除语义指令，执行 clear_track                     # E3：clear_words 拦截短路
追踪 id999 → 未找到该 ID 目标                                            # E5：不存在的 id
# E6：连发指令撑满队列 → put_nowait 满丢最旧（q maxsize=8，L220/L247-250）

步骤 4 · 断网注入 → 规则兜底 + ReID 降级：

pkill -f llm_server        # 或 config 关 llm.enabled=false 重跑
python3 apps/track_app.py --video .../test.mp4 --text --mjpeg
小飞小飞 → 追踪 id3
[track_app] chat fallback failed → _rule_fallback L620-628：parse_instruction 直解 → 追踪/清除仍可用
[LLM] 没听懂…              # 闲聊无规则可兜——设计预期不是缺陷
# ReID 全 worker 崩：extract get(timeout=10) 超时 → 全零特征
# pipeline L44-52：features 长度≠dets 数 → 归零 → tracker.update(dets, features=None) 纯 IoU，不断流

步骤 5 · 相机/aplay 注入 + 完整性收尾：

python3 apps/track_app.py --camera --mjpeg
# 注入① 拔相机线：连续 30 次读帧失败（_cam_fail>=30，engine L115-122）
{"t": ..., "kind": "camera_stall"} + 暂停 1s 周期重连（其余失败仅 sleep 0.2s）
{"t": ..., "kind": "pause_timeout"}  # LLM 挂死期间 pending 超 30.0s → 清 pending 解冻（L101-107）
# 注入② 另终端杀播放器看降级：
kill -9 $(pgrep aplay)   → _restart_playback 重启；持续失败置 _failed → 打印降级，状态机不卡 SPEAKING
tail -f runs/logs/events.jsonl   # 收尾：核对本轮产生的各 kind 是否齐全

09重点与易错点

• fail-closed 的判据只有一条：该分支是否调用了 submit_effect()。任何"不确定锁谁"（id 不对齐 / VLM 无果 / 解析失败）都必须零副作用，只回引导。
• 绝不空 submit：submit_effect(set()) 会清掉当前锁定——"追踪一百号"导致 id3 被误解锁，就是灾难级误导误锁。
• lost 是差分不是单帧：DeepSORT confirmed 目标 max_age=70 帧内仍存活，判定用帧间 confirmed 集合差分（prev_ids−cur_ids），单帧检测缺失不算丢。
• unlock_all 只在"全解锁"时写：clear_track 或 unlock_on_loss 全丢两条路径；follow 集合仍非空的部分丢失只写 lost。
• 没 follow 就没有 lost：纯视觉 video 不追踪时日志里不出 lost 属正常——先"追踪 id3"再等出画。
• 完整性 = 产生的都有写：pause_timeout/camera_stall 未出现只说明故障没触发；排查先区分"未触发"与"丢了日志"（写失败本身被吞）。
• 断网后闲聊不可是预期：_rule_fallback 只覆盖追踪/清除/截图三类；若断网后连追踪都不行，查 parse_instruction 与 registry.tools。
• 注入后必须恢复：llm_server、aplay、相机节点、events.jsonl 清空状态都要复位，否则污染下一实验。

10总结与思考

本实验把系统的"下限"补齐了：events.jsonl 让状态变化可追责（五类 kind 各答一个问题），fail-closed 三条闸门（清除短路 / id 对齐 / VLM 收口）保证"不确定就零副作用"，四条降级链（规则兜底 / 纯 IoU / 播放重启 / 引导语）保证"任何异常都收敛、不挂起"，两个看门狗（camera_stall、pause_timeout）保证外部依赖卡死不冻结主循环。这是从"能跑"到"敢上线"的关键一跃。产出：E1-E3 执行表、四类注入降级记录、jsonl 完整性核对。