F-043 (P6) — Eager startup discovery with `CancellationToken.None`, redundant to the hosted services

[LarsLaskowski]

Severity: 🟡 · Criterion: K4 / K5 · Phase: P6 · Status (review): 🆕

File(s): src/DockerUpdateGuard/ApplicationInitializationExtensions.cs:39-44; cross-reference hosted services src/DockerUpdateGuard/ServiceCollectionExtensions.cs:129-135

Finding

After the migration, the initialization synchronously runs
SynchronizeConfiguredInstancesAsync, SynchronizeAccountImagesAsync and
RefreshInventoryMetricsAsync — each with CancellationToken.None. The same
discovery work is done anyway by the registered hosted services
(DockerInstanceDiscoveryBackgroundService, DockerHubAccountImageDiscoveryBackgroundService)
periodically; the eager call is thus largely redundant. CancellationToken.None means:
even a SIGTERM during a slow startup sync (Docker Hub network) does not abort the operation
— readiness is delayed until all three steps (bounded by the HttpClient timeout)
complete. On the positive side: the network errors themselves are degraded rather than thrown
(SynchronizeAccountImagesAsync checks ExternalOperationResult.Status, :188-194;
SynchronizeConfiguredInstancesAsync is pure config/DB work) — so an unreachable
Docker Hub/instance does not crash the startup.

Impact

Delayed/blocked readiness at boot, not abortable on shutdown;
duplicate initial execution of the discovery. No correctness/security consequence.

Recommendation

Pass the app-lifetime token (IHostApplicationLifetime.ApplicationStopping) instead of
CancellationToken.None; leave the initial discovery to the hosted services
(e.g. "RunOnStartup" in ScheduledBackgroundService) or time-box it, so that startup
does not hang on external services.

---

_{Auto-generated from the repository code review. Source of truth: docs/review/findings.md → F-043 (P6), branch review/review-analysis-plan.}