中断的同步执行在指标中是看不见的 - 检查点停止的同步循环永远持续,同时报告成功

The chain (file:line refs from master) 1. Lambda executions get interruptAfterMs — packages/jobs/lib/execution/sync.ts:215 2. Graceful interruption produces error.type === 'execution_interrupted', which is converted to success: handleSyncSuccess({..., interrupted: true}) — packages/jobs/lib/execution/operations/handler.ts:59-61 3. In handleSyncSuccess: - interrupted goes into the operation log payload only (logCtx.enrichOperation meta) - the log message text reads "…completed successfully" either way — sync.ts:~520 - updateSyncJobStatus(SUCCESS) and setTaskSuccess — counted as success - nextExecutionInMs: 0 — immediate re-run — sync.ts:541 4. No metric anywhere carries interrupted. FUNCTION_EXECUTIONS (packages/metering/lib/processors/usage.ts:236) has dimensions {type, success, accountId, frequencyBucket, functionRuntime} — success is true for interrupted runs. TASKS_FAILED/TASKS_EXPIRED never fire. ### Why routing doesn't prevent it packages/jobs/lib/runtime/runtimes.rules.ts:29 keeps checkpoint-less syncs off the Lambda fleet — but only when plan.sync_lambda_checkpoint_required is set, and only by checking whether the sync declares the checkpoints feature. A sync that declares a checkpoint schema but whose checkpoint does not advance (stalled Cursor, buggy customer code saving the same value, dataset growing faster than the cap allows) passes routing and loops forever. Capability is checked; progress never is. ### The fix is cheap because the data is already in hand handleSyncSuccess already receives both interrupted and checkpoints: CheckpointRange ({from, to} — packages/types/lib/checkpoint/types.ts:22). Detecting the pathological state is a comparison of two values already in scope: