Context
Follow-up from #1279 / #1282 (merged in e7bb2625).
Problem
DaemonApi resolves its endpoint once at construction (_endpoint = ResolveEndpoint(paths)), and the init wizard's post-restart readiness poll (HealthCheckStepViewModel → DaemonApi.IsHealthyAsync) uses that frozen value. After the rework, the wizard applies a Daemon-section change by writing config and waiting for the in-process restart — but if that change alters the bind port, the daemon comes back on the new port while DaemonApi._endpoint still points at the old one. The poll then targets the dead address and times out at ReloadReadyTimeout (90s) despite a healthy daemon.
Why it's latent today
The init wizard's ExposureModeStepViewModel doesn't currently write a non-default Daemon.Port, so the port stays 5199 and the frozen endpoint happens to stay correct. But the rework's premise is "write any Daemon-section change → wait for health," and a port change is a valid Daemon-section change — so this is a real fragility waiting on a future wizard step (or an agent/operator config path) that does change the port. (The new container smoke test's Phase A exercises exactly a port change, but from the host side via curl, not through DaemonApi.)
Proposal
Re-resolve the endpoint at poll time (or derive the readiness URL from the just-written config's Daemon.Host/Port) rather than relying on the value captured at CLI startup.
Scope
Latent correctness fragility; non-blocking. Orthogonal to #1279/#1282.
Context
Follow-up from #1279 / #1282 (merged in
e7bb2625).Problem
DaemonApiresolves its endpoint once at construction (_endpoint = ResolveEndpoint(paths)), and the init wizard's post-restart readiness poll (HealthCheckStepViewModel→DaemonApi.IsHealthyAsync) uses that frozen value. After the rework, the wizard applies aDaemon-section change by writing config and waiting for the in-process restart — but if that change alters the bind port, the daemon comes back on the new port whileDaemonApi._endpointstill points at the old one. The poll then targets the dead address and times out atReloadReadyTimeout(90s) despite a healthy daemon.Why it's latent today
The init wizard's
ExposureModeStepViewModeldoesn't currently write a non-defaultDaemon.Port, so the port stays5199and the frozen endpoint happens to stay correct. But the rework's premise is "write anyDaemon-section change → wait for health," and a port change is a validDaemon-section change — so this is a real fragility waiting on a future wizard step (or an agent/operator config path) that does change the port. (The new container smoke test's Phase A exercises exactly a port change, but from the host side viacurl, not throughDaemonApi.)Proposal
Re-resolve the endpoint at poll time (or derive the readiness URL from the just-written config's
Daemon.Host/Port) rather than relying on the value captured at CLI startup.Scope
Latent correctness fragility; non-blocking. Orthogonal to #1279/#1282.