ops: scheduled live-domain monitor for the deployed product (PT-17)#602
Conversation
Nothing exercised the deployed product after release, so a broken domain, dead health probe, or lost route could only be discovered by a user. Probe https://psychiatry.tools every six hours with plain unauthenticated GETs: the app shell renders, /api/health reports ok in live (non-demo) mode, the key public routes answer 200 (following the /applications -> /tools canonicalisation either side of that landing), and the www alias resolves. No secrets, no third-party actions, and a repository variable (LIVE_DOMAIN_URL) can repoint it. A red run is the alert; deeper answer-SLO probing stays in the secret-gated ops digest. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
📝 WalkthroughSummary by CodeRabbit
WalkthroughChangesThe pull request adds a scheduled and manually triggered GitHub Actions workflow that probes the configured public domain. It verifies the application shell, live health status, critical route availability, and canonical production WWW connectivity. Live domain monitoring
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant GitHubActions
participant LiveDomain
participant HealthEndpoint
participant CriticalRoutes
GitHubActions->>LiveDomain: Fetch root and verify Clinical Guide
GitHubActions->>HealthEndpoint: Fetch /api/health
HealthEndpoint-->>GitHubActions: Return status ok and demoMode false
GitHubActions->>CriticalRoutes: Request configured routes
CriticalRoutes-->>GitHubActions: Return HTTP 200 responses
GitHubActions->>LiveDomain: Check canonical WWW endpoint when applicable
Caution Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional.
❌ Failed checks (1 error, 1 warning)
✅ Passed checks (9 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/live-domain-monitor.yml:
- Line 29: Align the workflow job timeout with the worst-case runtime of all
eight sequential probes, including curl max time, retries, and retry delays;
update each affected timeout-minutes setting to exceed that retry budget so
every route can complete before termination.
- Line 37: Update each curl check in the live-domain monitor workflow to capture
url_effective while following redirects, then validate that the final URL
remains HTTPS and has the same origin as LIVE_DOMAIN_URL before accepting the
response as successful. Apply this consistently to all four monitored requests,
preserving the existing body/status checks and failing the workflow on origin or
scheme mismatches.
- Around line 18-19: Update the workflow-level permissions configuration in the
live-domain monitor workflow to use an empty permission set, removing the
unnecessary contents: read grant. Keep the anonymous HTTP probe behavior
unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: b7112715-13ed-43d3-944b-7f823923994d
📒 Files selected for processing (1)
.github/workflows/live-domain-monitor.yml
| permissions: | ||
| contents: read |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Remove the unused repository token permission.
This workflow only performs anonymous HTTP probes and does not checkout code, call GitHub APIs, or use actions. Granting contents: read is unnecessary; use permissions: {} instead.
As per coding guidelines, GitHub workflow automation must use narrow permissions.
Proposed fix
-permissions:
- contents: read
+permissions: {}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| permissions: | |
| contents: read | |
| permissions: {} |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/live-domain-monitor.yml around lines 18 - 19, Update the
workflow-level permissions configuration in the live-domain monitor workflow to
use an empty permission set, removing the unnecessary contents: read grant. Keep
the anonymous HTTP probe behavior unchanged.
Source: Coding guidelines
| probe: | ||
| name: Probe public domain | ||
| runs-on: ubuntu-24.04 | ||
| timeout-minutes: 10 |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Align the job timeout with the retry budget.
There are eight sequential probes. With --max-time 30, --retry 2, and two 10-second retry delays, transient failures can consume roughly 14 minutes 40 seconds, exceeding timeout-minutes: 10. The job may be terminated before all routes are checked.
Possible fix
- timeout-minutes: 10
+ timeout-minutes: 20Alternatively, reduce the per-request retry budget while preserving the desired alert latency.
Also applies to: 37-37, 46-46, 63-63, 80-80
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/live-domain-monitor.yml at line 29, Align the workflow job
timeout with the worst-case runtime of all eight sequential probes, including
curl max time, retries, and retry delays; update each affected timeout-minutes
setting to exceed that retry budget so every route can complete before
termination.
| - name: Root renders the app shell | ||
| run: | | ||
| set -euo pipefail | ||
| body="$(curl -sSL --fail --max-time 30 --retry 2 --retry-delay 10 --retry-all-errors "$LIVE_DOMAIN_URL/")" |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
Validate redirect destinations before reporting success.
-L accepts cross-origin redirects and HTTPS-to-HTTP downgrades. A route could redirect to another server that returns the expected body or 200, causing a false-green monitor and unintended outbound requests from the runner. Capture url_effective and require the final origin to match the configured domain and remain HTTPS.
Also applies to: 46-46, 63-63, 80-80
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/live-domain-monitor.yml at line 37, Update each curl check
in the live-domain monitor workflow to capture url_effective while following
redirects, then validate that the final URL remains HTTPS and has the same
origin as LIVE_DOMAIN_URL before accepting the response as successful. Apply
this consistently to all four monitored requests, preserving the existing
body/status checks and failing the workflow on origin or scheme mismatches.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b5b5ab680d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # -L follows the /applications -> /tools canonicalisation either side | ||
| # of that redirect landing, so this list survives route renames. | ||
| for route in /privacy /services /forms /differentials /applications; do | ||
| code="$(curl -sSL -o /dev/null -w '%{http_code}' --max-time 30 --retry 2 --retry-delay 10 --retry-all-errors "$LIVE_DOMAIN_URL$route")" |
There was a problem hiding this comment.
For the key-route probes, and again in the www probe below, a transient HTTP 500/502/503 enters curl's retry path, but this exact -o /dev/null --retry ... command on the ubuntu-24.04 curl 8.5.0 runner exits 23 while trying to truncate /dev/null, so it makes only one request and never reports the final status; curl --help all describes --retry as retrying transient problems and --fail as making HTTP errors fail fast, and adding --fail made a local 500-then-200 reproduction retry successfully. That means a healthy route behind a brief edge/deploy 5xx can make the scheduled monitor go red despite the intended two retries, so the probe should fail/retry HTTP errors without using this /dev/null retry path.
Useful? React with 👍 / 👎.
1 participant
Summary
Audit PT-17: nothing exercised the deployed product after release, so a broken domain, dead health probe, or lost route could only be discovered by a user.
Adds
.github/workflows/live-domain-monitor.yml: every six hours (plus manual dispatch) it probes the public domain with plain unauthenticated GETs —/renders the Clinical Guide shell,/api/healthreportsstatus:okanddemoMode:false(catches lost live configuration, not just downtime),/privacy,/services,/forms,/differentials,/applicationsanswer 200 (with-L, so the/applications→/toolscanonicalisation passes either side of fix(ia): canonicalise Tools route and unify medication/composer naming (PT-11, PT-12, PT-14) #591),wwwalias resolves with valid TLS.No secrets, no providers beyond what any anonymous visitor triggers, no third-party actions (nothing to pin).
LIVE_DOMAIN_URLrepository variable repoints it (the www check auto-skips when overridden). A red run is the alert; deeper answer-SLO probing stays in the secret-gated ops digest.Verification
Equivalent curl probes run green against production just now (root 200 ~1.2s, health ok/live, all routes 200, www 200).
check:github-actions,check:ci-scope, prettier green.🤖 Generated with Claude Code