mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 10:59:59 +00:00
kevinveenbirkenbachandClaude Opus 5
2c192ab7e6
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>
5 lines
137 B
YAML
5 lines
137 B
YAML
---
|
|
# default vhost flavour
|
|
webserver_vhost_flavour: "basic" # valid: basic, ws_generic
|
|
front_proxy_stale_config_status_codes: [-1, 404]
|