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
fix: give vm.snapshot / vm.restore a 10-minute heavy-op timeout
The CH REST client utils.NewSocketHTTPClient sets http.Client.Timeout
to 30 seconds, which fires regardless of any context.WithTimeout at
the call site. vm.snapshot and vm.restore write/read the entire VM
memory image; on multi-GiB Windows snapshots over GCE standard
persistent disk, or for mid-boot snapshots still dirty with Windows
init activity, 30s is marginal and occasionally exceeded.
DoWithRetry masks the symptom by retrying 4x, but each attempt hits
the same 30s ceiling, so the user-visible effect is a ~2-minute wait
followed by "Client.Timeout exceeded while awaiting headers".
Fix: add heavyClient(hc) that clones the caller's http.Client by
value and raises Timeout to 10 minutes. The Transport (socket dialer
and connection pool) stays shared, so light endpoints like vm.pause
and vm.resume still use the original 30s client unchanged. Only
vm.snapshot and vm.restore route through heavyClient.
10 minutes was chosen to give multi-GiB cold-start restores real
headroom on slow disks while still bounding a genuine CH hang. The
global HTTPTimeout stays 30s to keep fast endpoints responsive.
Observed: epoch snapshot round-trip test against cocoonset-node-2
(2 GiB memory, freshly-booted Windows 11) — vm.restore timed out
with the default 30s client during cocoon vm clone even though the
memory-ranges file, disk, and network were all healthy.
0 commit comments