现状:sync-incremental.scheduler 不注入 AlertService。轮次失败只 logger.error 就吞掉(`:38` 注释「跑失败:log ERROR 不抛」),唯一出口是次日 09:07 的每日健康 报告 —— 最坏晚 24 小时。09-04 生产宕 11.8 小时全程零告警,有这一份原因。 而刚加的 compose mem_limit(8g)会把下面这条路径变成常见路径: 容器被 SIGKILL → 轮次失败 → HTTP 30 秒内恢复 → 外部探针一路绿 即**系统在稳定地失败,而所有指示灯是绿的**。不补这三条,新加的兜底反而 制造了一种更隐蔽的故障。 三条信号: 1. 回收到僵尸锁 → warning。这是「上一轮没正常终结」的**唯一确定性信号**, 比"轮次失败"更早更准:失败可能只是网络抖动,留下僵尸锁则意味着进程被 外力打断、没走到 finally。正文直接给 CONSTRAINT_MEMCG 的查法,并写明 别看 docker inspect 的 ExitCode(restart:always 下那是重启后那条命)。 2. 轮次抛异常 → critical,带错误原文。 3. 套圈跳过 → warning。这是 08-29 雪崩的前兆、也是 09-04 的中间态 —— 当时 11.8 小时里每轮都在这里 return,防套圈闸救了系统却**吞掉了症状**。 告警统一走 alertSafe:推送失败绝不能反过来打断同步。 测试:5 个新用例,并做了变异测试 —— 逐条拆掉告警 / 拆掉 try/catch, 四次变异全部被咬红,不是走过场的绿。全量 1975 passed。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
