Fix schedule-triggered workflow false positives and surface disabled-workflow root cause in health monitor - #53881
Conversation
… disabled-workflow root cause Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
Thanks for working on the Agent Job Health Monitor fix! 🩺 This is a solid hardening of the schedule-trigger detection logic — restricting the YAML scan to frontmatter (between What looks good:
Minor note:
|
|
Triage: category= Tiny targeted fix (4+/3-) for health-monitor false positives. Draft — undraft to run CI; low risk, ready for quick batch review alongside other monitor/docs PRs.
|
There was a problem hiding this comment.
Pull request overview
Hardens schedule-health monitoring to avoid false positives and identify disabled workflows.
Changes:
- Restricts schedule detection to YAML frontmatter.
- Reports disabled workflow states and re-enable guidance.
- Refreshes generated lock metadata.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/agent-job-health.md |
Updates heartbeat-check instructions. |
.github/workflows/agent-job-health.lock.yml |
Updates the generated body hash. |
Review details
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Balanced
| - List every workflow file with a `schedule:` trigger declared in the actual YAML frontmatter block of `.github/workflows/*.md` (the content between the first two `---` delimiters only — ignore any `schedule:` text that appears in the markdown body, such as documentation examples or sample snippets, which do not represent real triggers). Exclude the `shared/` includes and workflows whose only frontmatter trigger is `workflow_dispatch`. | ||
| - For each schedule-triggered workflow, resolve the expected cadence from its cron alias or expression (for example `daily` → 24h, `weekly` → 7d, `hourly` → 1h; for an explicit cron string, derive the implied interval). | ||
| - Use the GitHub Actions API (`list_workflow_runs` on the corresponding `.lock.yml`, any status, most recent first) to find the timestamp of the **most recent run of any kind** (not just successful runs) for that workflow. | ||
| - Flag a **blind spot** when the gap since that last run exceeds `2x` the expected cadence plus one day of slack (for example, a daily workflow silent for more than 3 days, or a weekly workflow silent for more than 15 days). | ||
| - For each blind spot, record: workflow name, `.lock.yml` path, last observed run timestamp, expected cadence, and the gap size in days. | ||
| - Before reporting a blind spot, also fetch the workflow's `state` (via `get_workflow` on the `.lock.yml`). If `state` is `disabled_manually` or `disabled_inactivity`, that is the root cause (not a silent cron misfire) — call this out explicitly in the report and recommend re-enabling the workflow (for example `gh workflow enable <workflow>`) rather than treating it as an undiagnosed schedule blind spot. |
The Agent Job Health Monitor flagged
craft,daily-hippo-learn, andsmoke-cias scheduled workflows that silently stopped firing. Investigation found each had a different root cause, none of which was an actual code or cron bug.Findings
on.slash_command; theschedule:text the monitor matched was an example snippet in the markdown body (documentation shown to the craft agent), not real frontmatter.craft.lock.ymlhas no schedule trigger.state: disabled_manually. Their compiled.lock.ymlschedule triggers are correct and match source — the workflows were simply switched off, not misconfigured.Changes
agent-job-health.md:---delimiters) instead of scanning the whole markdown body, eliminating false positives from documentation/example content.stateviaget_workflowand, when it'sdisabled_manually/disabled_inactivity, report that explicitly as the root cause with a recommendation to re-enable, instead of reporting an undiagnosed blind spot.agent-job-health.lock.ymlchanged as a result.Follow-up outside this PR's scope
daily-hippo-learnandsmoke-cistill need to be re-enabled by someone withactions:writeaccess, e.g.:No agentic workflow in this repo is granted
actions:write, so this can't be automated from within a workflow run.