3 Commits

Include renames

Author	SHA1	Message	Date
magnusandClaude Opus 5	7ea25ee4fd	Retry the Harbor manifest copy instead of a probe for it ... The companion SHA tag step failed on the last build even though the image had already been pushed and deployed. Harbor's vulnerability policy blocks manifest reads while Trivy's scan is Running, and `imagetools create` copies the manifest, so Harbor answered 412 Precondition Failed. Two faults compounded. The loop gated on `imagetools inspect`, but a probe passing is no guarantee the copy will be allowed. And `create` sat outside the condition, so under the default `bash -e` its first failure aborted the step before `exit 0` or any further attempt: the log shows one waiting line, then the error, with 58 of 60 retries unused. Retry the real operation instead, inside the condition so a blocked copy is a reason to wait rather than fatal. The trade-off is that a permanently failing copy now takes the full ten minutes to report instead of failing fast; the previous behaviour failed fast but wrongly, on a transient block. Also records that only the primary tag matters for rollout, since the Flux image policy matches the timestamp tag, so a failure in this step costs the audit tag rather than the deployment. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-10-11 09:56:26 +02:00
magnusandClaude Opus 5	4a2d8fabad	Recover from a btcdata restart without reloading the page ... htmx's WebSocket extension reconnects only after close codes 1006/1011/1012/1013. _ws_proxy closed the browser socket with a normal 1000 on every upstream exit, so htmx read a btcdata restart as a deliberate shutdown and left both panels frozen until the visitor reloaded. New browser connections always worked, which hid the defect from non-browser checks. The proxy now reconnects upstream behind the still-open browser socket on a bounded schedule, resets that schedule after a connection that lasted long enough to count as healthy, and closes with 1012 only once the schedule runs out, so recovery falls back to htmx's own backoff. A concurrent reader detects a departed browser, which a dead upstream would otherwise be indistinguishable from, and an unrenderable payload is logged and skipped rather than ending the stream. tests/test_ws_proxy.py covers this against a real loopback WebSocket server: same socket recovery across an upstream restart for both streams, the retryable close code when the upstream stays down, and skip-on-unrenderable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-10-11 09:21:19 +02:00
magnus	dd7058b6bd	Add agent project guidance	2026-09-17 15:02:42 +02:00