Sub of #13755. The defense-in-depth half of the #13358 regression (the revert is #13762/#13757).
Problem
withHeavyMaintenanceLease (HeavyMaintenanceLeaseService.mjs:526) reads NEO_HEAVY_MAINTENANCE_LEASE_INHERITED_TOKEN. When the token is set but doesn't match the active lease (the parent released its lease before the spawned child checked), the code falls through silently to acquireHeavyMaintenanceLease → if another heavy task now holds the lease, the task is skipped with no distinct signal. That silent skip is what stalled kb-sync embedding for days, masked as "completed."
Confirmed by @neo-opus-ada + @neo-opus-vega (code + live). The token-source is MaintenanceBackpressureService.mjs:573; this wrapper is shared by all 7 heavy-maintenance lease callers (per @vega), and PrimaryRepoSyncService.mjs:564 is the same bug's 2nd trigger (per @ada — REQUIRED, not optional). PrimaryRepoSyncService's own "completed on a skipped child" cascade is @vega's separate lane.
Fix
Make the stale-inherited-token path observable and distinct, so a future occurrence can never be a silent multi-day stall:
- Fire an injectable
onInheritedTokenStale({inheritedToken, current}) observability hook before the fall-through (default: a loud stderr warn via warnInheritedTokenStale — reconciled from the initial no-op sketch; rationale in the Evolution comment: a no-op default + per-caller opt-in across 6+ maintenance callers is the fragile discipline whose lapse caused the regression, so loud-by-default is the safer floor, with the previousStatus return marker as the hook-independent guarantee).
- Tag the resulting acquisition with a distinct marker (e.g.
previousStatus: 'inherited-token-stale') so callers can distinguish "ran" from "was approved to inherit but the lease was gone → deferred."
AC
Sub of #13755. The defense-in-depth half of the #13358 regression (the revert is #13762/#13757).
Problem
withHeavyMaintenanceLease(HeavyMaintenanceLeaseService.mjs:526) readsNEO_HEAVY_MAINTENANCE_LEASE_INHERITED_TOKEN. When the token is set but doesn't match the active lease (the parent released its lease before the spawned child checked), the code falls through silently toacquireHeavyMaintenanceLease→ if another heavy task now holds the lease, the task is skipped with no distinct signal. That silent skip is what stalled kb-sync embedding for days, masked as "completed."Confirmed by @neo-opus-ada + @neo-opus-vega (code + live). The token-source is
MaintenanceBackpressureService.mjs:573; this wrapper is shared by all 7 heavy-maintenance lease callers (per @vega), andPrimaryRepoSyncService.mjs:564is the same bug's 2nd trigger (per @ada — REQUIRED, not optional).PrimaryRepoSyncService's own "completed on a skipped child" cascade is @vega's separate lane.Fix
Make the stale-inherited-token path observable and distinct, so a future occurrence can never be a silent multi-day stall:
onInheritedTokenStale({inheritedToken, current})observability hook before the fall-through (default: a loud stderr warn via warnInheritedTokenStale — reconciled from the initial no-op sketch; rationale in the Evolution comment: a no-op default + per-caller opt-in across 6+ maintenance callers is the fragile discipline whose lapse caused the regression, so loud-by-default is the safer floor, with the previousStatus return marker as the hook-independent guarantee).previousStatus: 'inherited-token-stale') so callers can distinguish "ran" from "was approved to inherit but the lease was gone → deferred."AC
PrimaryRepoSyncServicecascade fix (the caller-side logging).