| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| cli | ||
| common | ||
| config | ||
| modules | ||
| openapi | ||
| prisma | ||
| queues | ||
| redis | ||
| types | ||
| app.module.ts | ||
| health.controller.ts | ||
| instrument.ts | ||
| main.ts |
现象:测试服 2026-07-23 8:00 报「DW 数据滞后」,增量游标 33.7h 未推进。
根因:sync_logs 用 partial UNIQUE(host_id) WHERE status='running' 作并发锁。
部署 force-recreate 重启 service 容器时,正在跑的同步进程被杀,但那行
running sync_log 来不及标终态 → 永久占住锁 → 之后每次 cron 增量都撞锁被
skip → 游标不动。代码注释早写了"进程崩需依赖 stale 清理",但该清理从未实现。
修复:SyncIncrementalSchedulerService.onModuleInit 注册 cron 前,先把 startedAt
早于本进程启动时刻(PROCESS_STARTED_AT)的 running 行标 failed。
判据安全性:sync 只在本 service 进程的 cron 回调、或一次性 CLI(跑完即退)里跑,
两者都不可能比本进程启动得更早还活着。反过来,本进程启动后新建的 running
(可能是并存的手动 CLI 真锁)用 lt 严格排除,绝不误清。
幂等:标 failed 只释放锁,不动数据 —— 游标没推进,下次增量靠 48h 回看窗补齐。
数据零丢失:回看窗默认 48h > 本次空档 33.7h,靠 source_event_id 幂等去重完整补回。
测试:sync-lock-reap.spec 覆盖 回收/lt判据锁/空启动/失败不抛;295 全绿。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| cli | Loading commit data... | |
| common | Loading commit data... | |
| config | Loading commit data... | |
| modules | Loading commit data... | |
| openapi | Loading commit data... | |
| prisma | Loading commit data... | |
| queues | Loading commit data... | |
| redis | Loading commit data... | |
| types | Loading commit data... | |
| app.module.ts | Loading commit data... | |
| health.controller.ts | Loading commit data... | |
| instrument.ts | Loading commit data... | |
| main.ts | Loading commit data... |