bug(envd): PostInit spawns unbounded MMDS-poll goroutines — one per /init retry

packages/envd/internal/api/init.go の PostInit から始め、特に 209-213 行を確認し、PollForMMDSOpts がどのように起動されるか、また initLock がそれとどのように関係するかを調べます。Issue で説明されている実行状態の guard を追加し、その後、/init の繰り返しのリトライによってアクティブな MMDS ポーリング goroutine が最大 1 つだけになる一方で、後続の resume サイクルでは再びポーリングできることを検証します。

Summary

PostInit unconditionally spawns a new goroutine on every call to poll MMDS. The orchestrator drives /init via an infinite retry loop, so when MMDS is not immediately reachable, goroutines accumulate inside the microVM without bound.

Root Cause

packages/envd/internal/api/init.go lines 209-213:

go func() {
ctx, cancel := context.WithTimeout(context.Background(), 60*time.Second)
defer cancel()
host.PollForMMDSOpts(ctx, a.mmdsChan, a.defaults.EnvVars)
}()

No guard prevents concurrent goroutine accumulation. initLock serialises body processing but the goroutine spawns after initLock.Release(1) so serialisation does not protect the spawn.

PollForMMDSOpts creates its own http.Client with DisableKeepAlives and ticks every 50ms issuing 2 HTTP requests per tick. Each goroutine lives up to 60 seconds.

Impact

At 100ms retry interval, 60 seconds of MMDS unavailability produces 600 concurrent goroutines, each making 40 connection-attempts/sec to 169.254.169.254 — 24000 TCP connections/sec total. This exhausts the VM ephemeral port range and can crash the envd control plane mid-resume.

Fix

Add an atomic.Bool guard to API struct and use CompareAndSwap in PostInit:

if a.mmdsPollRunning.CompareAndSwap(false, true) {
go func() {
defer a.mmdsPollRunning.Store(false)
ctx, cancel := context.WithTimeout(context.Background(), 60*time.Second)
defer cancel()
host.PollForMMDSOpts(ctx, a.mmdsChan, a.defaults.EnvVars)
}()
}

Caps concurrent MMDS-poll goroutines at 1 while preserving re-poll across resume cycles.