From f873c557ca517996e4ddb62023a48b60aeedea73 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Fri, 7 Aug 2026 03:57:18 +0200 Subject: [PATCH] final walk: the soak, and the window correction stated as mine MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Window 1 (22:44-01:54Z, untouched): every periodic job fired at its declared cadence — agent-channel-health 185x/1m, stack-scan 108x/2m, the 5-minute trio 44x each, hub-report 14x/15m. offsite-credential-retry ran 44 times and did no work and said nothing, which is R-218's asserted healthy-box behaviour on a box that never saw the defect. No alert, notification or digest fired; nothing on the must-not list fired. The off-site state never moved during that window — and that is NOT a finding. The daily jobs run on the controller's clock and the guest is UTC while the appliance is CEST, so the nightly local (~02:30) and off-site (~04:15) fall at 02:30Z and 04:15Z. I sized the window against CEST and it closed at 01:54Z, before either. Reporting 'the nightly did not fire' would have been a false finding produced by a badly-chosen window. Window 2 (corrective, 01:56-02:35Z) covers the 02:30Z local backup. The 04:15Z off-site nightly is deliberately NOT covered and is recorded as not run with the reason: leaving the machine at the claim screen before 07:00 is the primary deliverable, and waiting would have put the destruction at ~06:35 CEST with no margin. The off-site tier was exercised four times manually instead, including a full listing by name. --- .../finalwalk-r201-2026-08-07/journal.md | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/documentation/tests/finalwalk-r201-2026-08-07/journal.md b/documentation/tests/finalwalk-r201-2026-08-07/journal.md index 8ed34bb..c57ebb0 100644 --- a/documentation/tests/finalwalk-r201-2026-08-07/journal.md +++ b/documentation/tests/finalwalk-r201-2026-08-07/journal.md @@ -110,3 +110,40 @@ separate folder and left live data untouched). **T2 and T3 are the same finding as the headline**, seen from the customer's side: the fixes are written and pushed but not delivered, so tonight's box still exhibits both defects. + +--- + +## Phase B.1 — the soak + +**Window 1: 22:44:05Z → 01:54:03Z (3 h 10 m), untouched.** + +Every periodic job fired at exactly its declared cadence, which is the positive control that the +scheduler was running at all: + +| job | cadence | fired | expected in 190 min | +|---|---|---|---| +| `agent-channel-health` | 1 m | 185 | ~190 | +| `stack-scan` | 2 m | 108 | ~95 | +| `system-health` · `backup-cache` · **`offsite-credential-retry`** | 5 m | 44 each | ~38 | +| `hub-report` | 15 m | 14 | ~13 | +| `tier` · `fill-watch` · `db-dump` | — | 1 each | — | + +**`offsite-credential-retry` ran 44 times and did no work and said nothing.** That is R-218's asserted +healthy-box behaviour — the job exists, ticks, completes in 0 s, and stays silent because the +declaration it keys on is false. A box that had never seen the defect behaves exactly as designed. + +**No alert, notification or digest fired. Nothing on the must-not list fired.** The off-site state was +unchanged throughout (`last_run` fixed at `22:38:54Z`, `snaps=1`, `12.0 MB`). + +> **AND THAT LAST LINE IS NOT A FINDING — IT IS MY PLANNING ERROR, STATED AS SUCH.** The daily jobs run +> on the CONTROLLER's clock, and **the guest is UTC while the appliance is CEST** (`date +%Z`: +> guest `UTC`, appliance `CEST`). The nightly local backup (~02:30) and off-site (~04:15) therefore +> fall at **02:30Z and 04:15Z**, and I sized the window against CEST — so it closed at 01:54Z, before +> either. Reporting "the nightly did not fire" as a defect would have been a false finding produced by +> a badly-chosen window, which is precisely the shape §6.1 warns about in the other direction. +> +> **Window 2 (corrective): 01:56Z → ~02:35Z**, to cover the 02:30Z local backup. The 04:15Z off-site +> nightly is deliberately **NOT** covered: finishing the walk and leaving the machine at the claim +> screen before 07:00 is the primary deliverable (§11.1), and waiting for it would have put the +> destruction at ~06:35 CEST with no margin. **Recorded as not run, with the reason** — the off-site +> tier was exercised four times manually tonight instead, including a full listing by name.