You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[PRODENG-3633] Add overall apply/reset deadline and surface retry errors (#668)
Option A from the ticket: a Manager-level timeout wrapper rather than
threading context.Context through all 30+ phase implementations.
phase.Manager gains a Deadline time.Duration field. Run races each
phase's Run() against the deadline in a goroutine; on timeout it returns
an error naming the in-progress phase instead of blocking forever, and
does not start the next phase. The phase's goroutine is left running on
timeout rather than force-stopped -- launchpad is a short-lived CLI
process, so it exits shortly after and reclaims it. This does not make
individual waits (WaitGroup.Wait, channel ops) cancellable, only bounds
the total time Run can spend.
Wired through a new Product.SetTimeout(time.Duration) method rather than
adding a parameter to Apply/Reset, so none of the existing callers
(cmd/apply.go, cmd/reset.go, test/integration, test/smoke/*) need to
change signatures; only cmd/apply.go and cmd/reset.go call it, from a new
--timeout flag defaulting to 90m (matching the longest existing smoke
test timeout in the Makefile). --timeout 0 disables the deadline.
Separately, pkg/product/mke/config/cluster_spec.go's pingHost (the MKE
health-check retry loop) only logged "waiting for MKE ... to become
healthy" on every attempt and never the actual failure reason mid-retry,
which is why diagnosing the original PRODENG-3594 deadlock cost a full
50-minute CI run. Added retry.OnRetry to log the real error on each
failed attempt. The final returned error already carried every attempt's
error via retry-go's own Error type; nothing was actually being
discarded, it just wasn't visible while waiting.
Audited every other sync.WaitGroup use in the codebase (connect.go,
disconnect.go, run_hooks.go) for the double-send-on-channel pattern that
caused the original deadlock: none have it, all use defer wg.Done() with
mutex-protected shared state instead of a fixed-capacity channel.
Signed-off-by: James Nesbitt <jnesbitt@mirantis.com>
0 commit comments