Skip to content

validate: give the production stack its cache port, the way the benchmark driver does - #1192

Merged
MDA2AV merged 1 commit into
mainfrom
fix/validate-yield-redis-for-production-stack
Aug 16, 2026
Merged

validate: give the production stack its cache port, the way the benchmark driver does#1192
MDA2AV merged 1 commit into
mainfrom
fix/validate-yield-redis-for-production-stack

Conversation

@MDA2AV

@MDA2AV MDA2AV commented Aug 16, 2026

Copy link
Copy Markdown
Owner

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_up stop the harness Redis sidecar before a stack that ships its own.

It did not fix the validate path, because validate.sh doesn't 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

Are we regressing?

The red check is new; the broken thing isn't. 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 stack's cache has never been able to bind during validation either — the short depends_on: - cache form 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_redis stops the sidecar before the compose up, _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 share one definition instead of a copy
  • entries subscribed to production-stack but not crud never set REDIS_CONTAINER, and the yield is a no-op for them

Verified

The three functions exercised against real containers:

--- sidecar up (as the crud check leaves it) ---      running: httparena-redis
--- production-stack yields the port ---              PRODSTACK_STOPPED_REDIS=true  (6379 free)
--- and gets it back afterwards ---                   running: httparena-redis
--- entry without crud (REDIS_CONTAINER unset) ---    no-op

bash -n clean. 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 next validate (fulmine) on the self-hosted runner.

🤖 Generated with Claude Code

…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.
@MDA2AV
MDA2AV merged commit a20508c into main Aug 16, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant