mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 02:54:26 +00:00
kevinveenbirkenbachandClaude Opus 5
1d54eb7367
The drift check that runs on an unchanged vhost escalated on any status the
app does not accept. That escalation notifies restart-openresty, whose handler
runs container service update --force at a measured 40.32s mean over 186 fires,
and openresty sets service_update_order stop-first, so the update stops the
serving task before the replacement starts.
A 5xx cannot justify that. OpenResty emits one only after a server block
matched and proxied, so the vhost is loaded and the proxy is not at fault.
Restarting it takes the front end away from every other vhost and leaves the
backend exactly where it was.
Require the status to be a stale-config signature as well, the same [-1, 404]
the sibling escalation has used since 2c192ab7e6. Ansible's uri returns -1 when
the TLS handshake is rejected, which is what default_server.conf.j2 does when no
server block matches, and 404 is what that same default server returns on port
80. Both mean the vhost is not loaded, which is the only case a task redeploy
repairs.
The sibling's reload arm is deliberately not copied. It reads openresty_reload,
which reload.yml registers only when a reload ran. This branch notifies nothing,
so the variable would carry the previous domain's result.
default(-1) keeps the test total. The probe has no when of its own and shares
the block guard with the escalation, so site_check is always registered and a
missing status can only mean a probe that got no response.
Across 98 job logs the block executed 6 times, answering 200 four times and 405
twice, and all six keep their outcome. The other 488 of 494 evaluations skipped
the block outright, because a fresh CI host renders every vhost as changed. A
repeat deploy of the same inventory is what reaches this branch.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>