From d41cd989e0060fb1f7b6a3b3d4de37469bdf66d8 Mon Sep 17 00:00:00 2001
From: Claude <noreply@anthropic.com>
Date: Tue, 1 Sep 2026 20:49:58 +0000
Subject: [PATCH] refresh-data: seasonal crons, longer timeout, loud failure
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Kaizen after two findings: (1) the Aug 18 manual refresh died at the
120-min job timeout and GitHub filed it as 'cancelled' — nobody heard,
and the app kept serving Aug 3 summer data until a human asked; (2)
seasonal schedule flips (school year, Christmas, Easter) relied on
remembering a manual dispatch.

- crons added: 1 Sep, 15 Dec, 15 Mar + 5 Apr (bracket most Holy Weeks);
  monthly 3rd stays. Extra runs are cheap — unchanged registry commits
  nothing.
- timeout 120 -> 300 min.
- failure or timeout now opens a labeled issue linking the run; the app
  keeps serving last good data either way.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RicgHjbdeNb3ZGA6DMYMfS
---
 .github/workflows/refresh-data.yml | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/refresh-data.yml b/.github/workflows/refresh-data.yml
index 0a8f1ee..d6a01a0 100644
--- a/.github/workflows/refresh-data.yml
+++ b/.github/workflows/refresh-data.yml
@@ -1,11 +1,16 @@
 # Scheduled registry refresh — P5/P6/P7 run on data freshness (docs/PERSONAS.md).
-# Monthly by cron; run manually (workflow_dispatch) the week before liturgical
-# peaks — Holy Week and 20–24 Dec — so late-published feast one-offs land in time.
+# Monthly by cron plus seasonal-boundary runs (parishes flip schedules at the
+# school year, Christmas, and around Easter); workflow_dispatch stays the escape
+# hatch for anything last-minute.
 name: Refresh data
 
 on:
   schedule:
     - cron: '17 2 3 * *' # 3rd of each month, 02:17 UTC
+    - cron: '17 2 1 9 *' # 1 Sep — school year starts, summer schedules end
+    - cron: '17 2 15 12 *' # 15 Dec — before the 20-24 Dec peak
+    - cron: '17 2 15 3 *' # 15 Mar + 5 Apr — Easter moves (22 Mar-25 Apr);
+    - cron: '17 2 5 4 *' #   two runs bracket most Holy Weeks
   workflow_dispatch:
 
 permissions:
@@ -19,7 +24,7 @@ concurrency:
 jobs:
   refresh:
     runs-on: ubuntu-latest
-    timeout-minutes: 120
+    timeout-minutes: 300 # Aug 2026: a manual run hit the old 120-min cap and died as 'cancelled'
     steps:
       - uses: actions/checkout@v4
       - uses: actions/setup-node@v4
@@ -73,3 +78,15 @@ jobs:
               "https://api.github.com/repos/${{ github.repository }}/actions/workflows/ci.yml/dispatches" \
               -d '{"ref":"main"}'
           fi
+
+      # A dead refresh must be loud (the Aug 2026 timeout surfaced only when a
+      # human asked why the data was stale). Failure AND timeout (which GitHub
+      # reports as 'cancelled') open/refresh an issue.
+      - name: Raise an issue when the refresh dies
+        if: failure() || cancelled()
+        run: |
+          curl -sS -X POST \
+            -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" \
+            -H "Accept: application/vnd.github+json" \
+            "https://api.github.com/repos/${{ github.repository }}/issues" \
+            -d "{\"title\":\"Registry refresh failed ($(date -u +%Y-%m-%d))\",\"body\":\"Run: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }} — status \`${{ job.status }}\`. The app keeps serving the last good data; re-run the workflow or investigate the scraper.\",\"labels\":[\"data\"]}"