fix(envd): make /init lock ctx-aware to prevent retry pile-up#2702
Conversation
If any /init is stuck inside SetData, the orchestrator's infinite retry loop pushes more callers behind sync.Mutex.Lock(), each holding a copy of the request body and a goroutine. Switch initLock to a buffered channel (capacity 1) and acquire via select on ctx.Done(); on cancellation return 503 so the orchestrator just retries with a stable Timestamp (PostInit is idempotent per #2687) instead of accumulating goroutines server-side.
PR SummaryMedium Risk Overview Potential issues: Reviewed by Cursor Bugbot for commit b3c2214. Bugbot is set up for automated code reviews on this repo. Configure here. |
❌ 11 Tests Failed:
View the full list of 11 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
There was a problem hiding this comment.
Code Review
This pull request replaces the sync.Mutex with a buffered channel in the PostInit handler to implement context-aware locking, preventing goroutine accumulation during timeouts. The package version is also updated to 0.5.24. I have no feedback to provide.
Orchestrator already logs the failure; doubling up here is noise.
Replaces lockMutexCtx (which spawned a goroutine per acquisition that lingered until lock release) with the same channel-as-mutex pattern #2702 uses for initLock. Foreground respects ctx for lock acquisition only; the actual install work always runs to completion.
Replaces
initLock(sync.Mutex) withsemaphore.Weighted(1). Contended /init returns 503 the moment the caller's ctx fires instead of accumulating goroutines + buffered bodies + memguarded token pages behind a non-ctx-aware mutex.