release: v1.15.1

CHANGELOG.md

@@ -7,6 +7,34 @@ All notable changes to RigForge are documented here. The format is based on
 
 ## [Unreleased]
 
+## [1.15.1] - 2026-08-15
+
+### Fixed
+
+- **An unreachable worker API no longer aborts the run, or cries abort while succeeding (#364).**
+  The API readers had a "propagate" mode that let curl's exit escape, so an unreachable miner would
+  "surface upstream". Nothing upstream ever read it — every caller branches on an empty body — and
+  letting it escape broke two different ways depending on the bash running the script:
+
+  - **Any caller that was not guarded aborted outright.** Measured on a rig (Linux, bash 5.2): with
+    the API refusing connections, `tune`/`autotune`'s sampling loop and a bare `_status_api_summary`
+    both died with `[ERROR] rigforge aborted ... (exit 7)`. An API that went away mid-sweep — the
+    miner restarting under you — took the sweep with it. This is the failure #210 first hit on
+    miner-0 and papered over with a `|| true` at one call site.
+  - **On bash 3.2 (macOS) even the guarded callers printed the abort banner.** `status` wraps its
+    read in `( ... ) || true` and still emitted two `[ERROR] rigforge aborted while running 'status'`
+    lines to stderr before printing its correct "worker API not reachable" line and exiting 0 — the
+    reported shape. `set -E` inherits the ERR trap into the `$( )` the caller reads through, and 3.2
+    does not carry the caller's suppressed-errexit context into that child, so the trap fires there
+    once per frame the failure unwinds through. Bash 5.2 does carry it and stays quiet, which is why
+    this showed up on dev machines and not on the rigs. Spending the line operators are taught to
+    read as "something broke" on a routine, handled, exit-0 path is what made #341's real abort easy
+    to miss.
+
+  The mode is gone. Both readers now always return 0 with an empty body when the API is unreachable
+  — the contract every caller already assumed — so neither failure shape is reachable, and #210's
+  guard-inside-the-`$( )` idiom is no longer needed for these readers.
+
 ## [1.15.0] - 2026-08-15
 
 ### Added

RELEASING.md

@@ -29,7 +29,7 @@ promoted to `main` and tagged. The steps below build the release commit on `deve
    sudo reboot                             # HugePages (1G + GRUB cmdline) take effect on boot; reconnect
    sudo bash tests/e2e-real.sh verify      # doctor (HugePages/MSR/governor/service) + bench (real H/s) + a short tune + a live auto-tune pass
    sudo bash tests/e2e-real.sh control     # the writable control path (#236) against real systemd: enable, POST a change, poll to applied, revert
-   sudo bash tests/e2e-real.sh upgrade     # the remote-upgrade chain (#308/#322) with REAL git: noop + refused-tag rollback legs, revert (opt-in forward leg: E2E_UPGRADE_TARGET=vX.Y.Z)
+   sudo bash tests/e2e-real.sh upgrade     # the remote-upgrade chain (#308/#322) with REAL git: noop + refused-tag rollback legs, plus a mandatory forward leg that auto-derives the previous real release tag -> current and proves it, then reverts (skip with a reason: E2E_UPGRADE_SKIP_REASON="...")
    sudo bash tests/e2e-real.sh perf        # offline bench vs the committed per-host baseline + best-ever history (the release perf gate)
    sudo bash tests/e2e-real.sh teardown    # uninstall + assert a clean revert
    ```
@@ -105,14 +105,19 @@ Pushing the tag triggers the release pipeline
 - creates the GitHub Release as a draft. Review the generated notes and bundles, then click
   Publish (pre-1.0 `0.x` tags are marked pre-release; `1.0.0`+ are full releases).
 
-After the fleet is re-tagged, record each rig's benchmark for the release
+After a rig is re-tagged, record its benchmark for the release
 (`E2E_PERF_TAG=vX.Y.Z E2E_PERF_RECORD=1 sudo bash tests/e2e-real.sh perf` on the rig) and commit
 the updated `tests/perf-baselines/` files — the per-release history is what lets the perf gate
-catch slow drift across releases (see `tests/perf-baselines/README.md`). The recording is also
+catch slow drift across releases (see `tests/perf-baselines/README.md`). In practice that means
+miner-0 every time, since the release gate itself always runs there (see
+[`tests/README.md`](./tests/README.md#the-shared-rig-miner-0)); the rest of the fleet isn't re-tagged
+on every release, so its baselines are only as fresh as the last time each rig was actually
+touched. `tests/perf-baselines/` legitimately carries gaps between releases for rigs that went
+untouched — it is not a promise that every rig has an entry for every tag. The recording is also
 the per-rig perf gate (#214): it judges against the committed baseline and best-ever history
 before writing, refuses to record a regressed number (fix it, or consciously override with
-`E2E_PERF_FORCE=1`), so a failed rig means investigate before calling the fleet healthy. Once the collected
-baselines are merged, reset each rig's copy (`sudo git checkout -- tests/perf-baselines/` in
+`E2E_PERF_FORCE=1`), so a failed rig means investigate before calling it healthy. Once a rig's
+baseline is merged, reset its copy (`sudo git checkout -- tests/perf-baselines/` in
 `/opt/rigforge`): the recording dirties the rig's checkout, and the *next* release's
 `git checkout <tag>` aborts on exactly those files (this bit both the v1.4.0 and v1.5.0 deploys).
 

VERSION

@@ -1 +1 @@
-1.15.0
+1.15.1