A control instance now retries fleet-sync pushes that hit a transient
failure and backfills the security state on a freshly registered remote
without waiting for the next policy edit.
New service:
- FleetSyncRetryService (singleton, start/stop) wakes 30s after boot
and ticks every 5min. For each fleet resource, queries
getFailedSyncTargets within a 24h window and re-pushes via
FleetSyncService.pushResourceToNode through the same per-node mutex,
so a normal fanout in flight serializes naturally with a retry.
- After STALE_THRESHOLD_MS (1h) of continuous failure for a
previously-working node, dispatches a single warning notification
per cooldown window. Brand-new nodes that have never succeeded do
not alert via this path; misconfigured remotes are caught by the
test-connection affordance at registration time.
- Wired into bootstrap startup/shutdown next to AutoHealService.
Public surface:
- FleetSyncService.pushResourceToNode(node, resource): targeted push
to one node that re-uses the per-node mutex. Used by the retry
service and any future targeted-resync flow.
- routes/nodes.ts POST /api/nodes fires pushResourceAsync for both
resources after a remote-proxy node row commits.
Tuning constants centralized in fleetSyncConstants.ts:
- RETRY_MAX_AGE_MS = 24h
- STALE_THRESHOLD_MS = 1h
Tests:
- 8 vitest cases covering replica skip, retry dispatch, missing-node
skip, alert-once-per-cooldown across the threshold window, no-alert
for recent failures, no-alert for brand-new never-succeeded nodes,
no-alert when the retry itself succeeds, start/stop idempotency.
- Full backend suite: 1781 pass / 5 skipped.
Anso