fix(cachix-push): bound the push and alert on failure#485
Open
etrobert-bot wants to merge 1 commit into
Open
Conversation
The post-build hook blocks `nix build`, and main CI never cancels, so a stalled or misconfigured cache wedges every cache-miss build until it times out — recently ~15-20 min per built path. cachix retries transient 5xx/429 with a bounded backoff but does not bound a stalled-open connection, so a hung upload was unbounded. Wrap the push in `timeout` (outer stop for stalls) and swallow its exit so a cache failure never fails the build — a push failing means the path just is not cached, not that the build is broken. To keep failures visible (a bad token or wrong cache name exits non-zero and fast), ping ntfy on any non-zero exit. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Tower's
post-build-hook(modules/cachix-push.nix) runscachix pushafter each locally-built path. Because the hook blocksnix buildand main CI never cancels (concurrency.cancel-in-progress: false), a stalled or misconfigured cache wedges every cache-miss build on main.This bit us today: renaming a derivation forced local rebuilds, and cachix's push endpoint was degraded such that uploads stalled on an open connection — each stuck push ran ~15–20 min before completing, dragging out CI and delaying pi's deploy.
cachix's own retry logic (v1.11.1) bounds transient
5xx/429failures (≤90 s cumulative backoff × 3 whole-op retries) but does not bound a stalled-open connection — there's no per-request response timeout — so a hung upload was effectively unbounded.Fix
Wrap the push in
timeoutand make it non-fatal:timeout 180— outer stop for the stalled-connection case cachix can't bound itself. A healthy push of a locally-built path takes <5 s, so this only trips when the cache is actually broken.CachixExceptionthat is not retried, so it exits non-zero and fast — thentfyping fires on the first cache-miss build. Usesntfy-wrappedviaself.packages, mirroringmodules/ntfy-failure-alerts.nix.Trade-off
The hook fires per built path, so a sustained cache outage during a large rebuild can emit a burst of alerts (one per path). It self-limits and only happens when the cache is genuinely broken (zero noise when healthy). If that burst is annoying, a follow-up could move health-alerting to a periodic canary that pings once via the existing
ntfy-failure@infra.Verification
nix evalofnixosConfigurations.tower...toplevel.drvPathsucceeds (module resolvesself/ntfy-wrapped/coreutils).🤖 Generated with Claude Code