Sub of #13755 (heavy-lease deferred-as-completed epic). The cascade sibling of #13785 — which fixed the ProcessSupervisorService kbSync task path; this is the separate PrimaryRepoSyncService cascade spawner, still unfixed.
Problem (V-B-A'd on live source)
PrimaryRepoSyncService.runKbSync (the primary-dev-sync → kbSync cascade, lines 583–601) runs ai:sync-kb via execFileSync and records recordTaskOutcome('kbSync', 'completed', …) + markCompleted('kbSync') on any non-throw (line 586-591). But syncKnowledgeBase.mjs exits 0 on a heavy-maintenance-lease-held deferral — now emitting {deferred:true, reason:'heavy-maintenance-lease-held'} on stdout (post-#13785). The cascade does not parse that stdout, so a lease-held cascade kb-sync is recorded as a false-green completed — the exact telemetry-lie #13785 killed for the task path, surviving in the cascade spawner.
This is the silent-stall failure class of #13755: a deferred cascade kb-sync looks healthy while no embedding happened.
Fix
runKbSync already captures stdout (stdio: ['ignore', 'pipe', 'pipe'], line 576; execFileSync returns it). Parse the child's JSON outcome and record skipped (reasonCode from the outcome) on {deferred:true} instead of completed — mirroring ProcessSupervisorService.classifySuccessfulChildOutcome. The emit side is already done by #13785.
Acceptance
- A lease-held cascade kb-sync records
recordTaskOutcome('kbSync', 'skipped', {reasonCode:'heavy-maintenance-lease-held', parent:'primary-dev-sync'}), not completed.
- A real cascade sync still records
completed with the embed/delete counts.
- Unit coverage in
PrimaryRepoSyncService.spec for both paths.
- Depends on #13785 (the emit side) being merged.
Evidence
L0 (V-B-A of live runKbSync, lines 583-601: try/execFileSync → markCompleted on no-throw, no stdout parse). No existing ticket (dup-sweep clean).
Authored by @neo-opus-vega (Vega), origin session d41446ed.
Sub of #13755 (heavy-lease deferred-as-completed epic). The cascade sibling of #13785 — which fixed the
ProcessSupervisorServicekbSync task path; this is the separatePrimaryRepoSyncServicecascade spawner, still unfixed.Problem (V-B-A'd on live source)
PrimaryRepoSyncService.runKbSync(theprimary-dev-sync → kbSynccascade, lines 583–601) runsai:sync-kbviaexecFileSyncand recordsrecordTaskOutcome('kbSync', 'completed', …)+markCompleted('kbSync')on any non-throw (line 586-591). ButsyncKnowledgeBase.mjsexits0on a heavy-maintenance-lease-held deferral — now emitting{deferred:true, reason:'heavy-maintenance-lease-held'}on stdout (post-#13785). The cascade does not parse that stdout, so a lease-held cascade kb-sync is recorded as a false-greencompleted— the exact telemetry-lie #13785 killed for the task path, surviving in the cascade spawner.This is the silent-stall failure class of #13755: a deferred cascade kb-sync looks healthy while no embedding happened.
Fix
runKbSyncalready captures stdout (stdio: ['ignore', 'pipe', 'pipe'], line 576;execFileSyncreturns it). Parse the child's JSON outcome and recordskipped(reasonCode from the outcome) on{deferred:true}instead ofcompleted— mirroringProcessSupervisorService.classifySuccessfulChildOutcome. The emit side is already done by #13785.Acceptance
recordTaskOutcome('kbSync', 'skipped', {reasonCode:'heavy-maintenance-lease-held', parent:'primary-dev-sync'}), notcompleted.completedwith the embed/delete counts.PrimaryRepoSyncService.specfor both paths.Evidence
L0 (V-B-A of live
runKbSync, lines 583-601: try/execFileSync →markCompletedon no-throw, no stdout parse). No existing ticket (dup-sweep clean).Authored by @neo-opus-vega (Vega), origin session d41446ed.