Live-reload passthrough-watcher healthPath instead of requiring a restart - #58
Conversation
watch.sh reads mode from a file each loop, but HEALTH_URL is a plain shell variable set once at process start from the ConfigMap-baked script text. A ConfigMap update (e.g. the healthPath fix in #56) never reaches an already-running watcher pod without a restart, so any tenant whose pod predated that fix was silently stuck polling /health/live — which always returns 200 — making both the manual bypass toggle and automatic dependency-outage failover no-ops. Add a checksum/config annotation on the pod template so config changes trigger a real rollout.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe passthrough watcher pod template now includes a checksum annotation for its ConfigMap. Changes to the annotation trigger a Deployment rollout. ChangesWatcher configuration rollout
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to The watcher now applies health-path ConfigMap changes without requiring a pod restart; no actionable merge-blocking risk remains after normal checks and review. Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.)
Comment |
HEALTH_URL was baked in once at process start, so a ConfigMap change (like #56's /health/live -> /health/passthrough fix) never reached an already-running watcher pod. Re-read healthPath from a file each loop, the same way mode already is, so a values change (or this ConfigMap already having drifted ahead of a stale pod) takes effect within one poll interval — no restart, no checksum annotation needed.
Summary
HEALTH_URLin the passthrough-watcher'swatch.shwas set once at process start from the ConfigMap-baked script text, so a ConfigMap update (e.g. Repoint bypass watcher healthPath to /health/passthrough #56's/health/live→/health/passthroughfix) never reached an already-running watcher pod./health/live, which always returns200regardless of dependency health or the bypass toggle — so both the manual bypass toggle and automatic failover-on-outage have been silent no-ops fleet-wide since before Repoint bypass watcher healthPath to /health/passthrough #56 shipped.healthPathis now re-read from a file each loop, exactly likemodealready is (see the existing "Re-read each loop iteration, so a values change applies live" comment). No restart, no checksum annotation — a ConfigMap change (from a values change, or a chart upgrade like this one) takes effect within one poll interval everywhere, automatically.Test plan
helm templaterenders cleanlyjsjvnsg-prod-aws-n-virginia,aejupnv-consumer-1-aws-us-east-2): after this ConfigMap update rolls out, watcher correctly picks up/health/passthroughwithin one poll interval, no pod restart — confirmed it flips the Service selector to passthrough for an account with the bypass toggle enabled, and reverts correctly🤖 Generated with Claude Code
Summary by CodeRabbit