validate: give the production stack its cache port, the way the benchmark driver does - #1192
Merged
Merged
Conversation
…mark driver does #1191 made the three production-stack compose files wait for a healthy cache, so a cache that cannot bind now fails the stack instead of being stepped over. It fixed the benchmark path at the same time, by having gateway_up stop the harness Redis sidecar before a stack that ships its own. It did not fix the validate path, because validate.sh does not source scripts/lib/gateway.sh - it carries its own compose handling. So validation started failing where it used to pass: dependency failed to start: container httparena-validate-gw-production-stack-fulmine-cache-1 exited (1) | Could not create server TCP listening socket 0.0.0.0:6379: bind: Address in use validate.sh starts its own Redis sidecar on 6379 whenever the entry subscribes to crud, and fulmine subscribes to both crud and production-stack. The cache has never been able to bind there either; the short depends_on form meant nobody found out, and validation was checking the stack against the sidecar's Redis rather than the one the profile configures. _prodstack_yield_redis stops the sidecar before the compose up and _prodstack_restore_redis brings it back, on the failure path as well as after teardown. The sidecar's docker run moves into redis_sidecar_start() so both callers use one definition rather than a copy. Entries that subscribe to production-stack without crud never set REDIS_CONTAINER, and the yield is a no-op for them. Verified by exercising the three functions against real containers: the sidecar is stopped and 6379 released, restarted afterwards, and left alone when REDIS_CONTAINER is unset.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Regression from #1191 — my fault, and this is the missing half of it.
#1191 made the three production-stack compose files wait for a healthy cache, so a cache that can't bind now fails the stack instead of being stepped over. It fixed the benchmark path at the same time, by having
gateway_upstop the harness Redis sidecar before a stack that ships its own.It did not fix the validate path, because
validate.shdoesn't sourcescripts/lib/gateway.sh— it carries its own compose handling. So validation started failing where it used to pass:Are we regressing?
The red check is new; the broken thing isn't.
validate.shstarts its own Redis sidecar on 6379 whenever the entry subscribes tocrud, andfulminesubscribes to bothcrudandproduction-stack. The stack's cache has never been able to bind during validation either — the shortdepends_on: - cacheform meant nobody found out, and validation was checking the stack against the sidecar's Redis rather than the one the profile configures. #1191 turned that silence into a failure everywhere; this PR makes the validate path able to succeed, the same way the benchmark path already can.The fix
_prodstack_yield_redisstops the sidecar before the compose up,_prodstack_restore_redisbrings it back — on the failure path as well as after teardowndocker runmoves intoredis_sidecar_start()so both callers share one definition instead of a copyREDIS_CONTAINER, and the yield is a no-op for themVerified
The three functions exercised against real containers:
bash -nclean. The full production-stack validation can't run on this box — the compose cpusets are benchmark-host ranges — so the end-to-end proof is the nextvalidate (fulmine)on the self-hosted runner.🤖 Generated with Claude Code