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

Start in packages/envd/internal/api/init.go at PostInit, especially lines 209-213, and inspect how PollForMMDSOpts is launched and how initLock relates to it. Add the running-state guard described in the issue, then verify that repeated /init retries leave at most one MMDS poll goroutine active while allowing a later resume cycle to poll again.

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.