kevinveenbirkenbachandClaude Opus 5 2c192ab7e6 perf(front-proxy): escalate to a redeploy only when the vhost is not loaded ...

The post-reload probe escalated on any status the app does not accept, and a
forced OpenResty task redeploy costs a measured 40.32s. In four CI job logs it
fired 11 times per job on 502 and 500 only, never on 404 and never on a
connection failure.

Those statuses refute the escalation rather than justify it. OpenResty emits
5xx after it has matched a server block and proxied, so they prove the vhost is
loaded and the reload took effect. The default server cannot emit them at all:
it returns 404 on port 80 and rejects the handshake on 443, and it carries no
proxy_pass. In eight of eight round-one escalations the upstream app had not
been deployed yet when its vhost was probed, the deploy trigger following the
502 by up to 52 seconds.

The log also holds a control. A full 40s redeploy completes three to six
seconds before every one of the 28 post-reload probes, notified by another
pending restart in the same flush. Seventeen then pass and eleven do not, same
proxy, same recency, so the differentiator is the backend. The escalation
answers that by running the same redeploy again, and nothing re-probes after it.

Narrow the trigger to the two signatures that do prove a stale configuration,
plus the case where the reload never landed because the container was
mid-recreate, which reload.yml tolerates. Worth 438 to 470 seconds per job.

The status test also gains the connection-failure case. Today the
`status is defined` clause excludes it, so the one symptom a genuinely stale
config produces could never fire the escalation at all.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-09 18:11:38 +02:00

..

main.yml

…