[aw] SelfCare: has stale lock file
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- github-actions, yaml
- Domain
- build-system, ci-cd
Research direction
The failing check compares the SelfCare workflow's source markdown against its compiled .lock.yml; search the repo for the self-care workflow .md file and check whether a .lock.yml sits beside it. Run gh aw compile (and gh aw compile --validate to confirm) after editing, then commit and push the regenerated .lock.yml. If the mismatch came from an install rather than an edit, the issue's own notes say to re-add with an exact SHA and recompile; done means the lock-file check passes on the next main run.
Written by the indexing model from the issue text.
Description
What happened
SelfCare has stale lock file.
View run #41644099611 · Previous failures
Branch: main
Next step
Review the failure details below for a targeted fix, or assign this issue to a coding agent to investigate.
Failure details
[!WARNING]
Lock File Out of Sync: The workflow could not start because its compiled lock file no longer matches the source markdown.
This means the workflow's .md file was edited but gh aw compile was not run afterwards to regenerate the corresponding .lock.yml file. The agent is prevented from running against a stale configuration to avoid unexpected behaviour.
To fix, recompile the workflow:
gh aw compile
Then commit and push the updated .lock.yml file.
More ways to recompile
Using the gh-aw MCP server (if configured):
{
"tool": "compile",
"arguments": {
"validate": true
}
}
Recompile all workflows at once:
gh aw compile --all
Verify the result:
gh aw compile --validate
How to investigate the mismatch
The workflow run logs contain a verbose debug pass that shows exactly what was hashed. Search the Check workflow lock file step logs for lines starting with [hash-debug] to see:
- The raw frontmatter text that was used as input
- Any imported files that were included in the hash
- The canonical JSON that was fed to SHA-256
- The resulting hash value
This makes it easy to spot accidental whitespace changes, encoding differences, or import path drift.
This mismatch can also happen on a fresh install (even without any manual edits) if gh aw add <path>@<ref> could not resolve the ref to an exact commit SHA during installation. In that case, rerun the add command with an exact SHA (or retry when API/rate-limit conditions recover), then recompile:
gh aw add <path>@<exact-sha>
gh aw compile
How to disable this check
[!CAUTION]
Disabling this check means the agent can run against an out-of-date compiled workflow. Only disable it if you have an alternative mechanism to keep lock files in sync.
Set stale-check: false in the on: section of your workflow frontmatter:
on:
issues:
types: [opened]
stale-check: false
After editing, recompile the workflow: gh aw compile
Copy a debugging prompt
Paste this into your coding agent:
Debug the agentic workflow "self-care" failure.
Follow https://raw.githubusercontent.com/github/gh-aw/main/debug.md
Failed run: https://github.com/githubnext/gh-cao/actions/runs/41644099611
If the repository includes the agentic-workflows skill, load it before investigating.
Manage failure notifications
To stop creating failure issues for this workflow, set this in its frontmatter and recompile:
safe-outputs:
report-failure-as-issue: false
This only disables issue reporting; it does not fix the failure.
- expires on Nov 4, 2026, 1:26 PM UTC
- Dominant language
- JavaScript
- Stars
- 8
- Forks
- 5
- Avg merge
- 3h 20m
- Merged PRs (30d)
- 811
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from githubnext/gh-cao
-
agentic-workflows
Difficulty 1/5 Under an hour Newbie friendliness 68/100
githubnext/gh-cao#20168 ·
Maintainers usually reply within 1 day
-
agentic-workflows
Difficulty 1/5 1-3 hours Newbie friendliness 75/100
githubnext/gh-cao#20155 ·
Maintainers usually reply within 1 day
-
agentic-workflows
Difficulty 1/5 Under an hour Newbie friendliness 78/100
githubnext/gh-cao#20154 ·
Maintainers usually reply within 1 day
-
agentic-workflows
Difficulty 1/5 1-3 hours Newbie friendliness 80/100
githubnext/gh-cao#20153 ·
Maintainers usually reply within 1 day
-
repo-assist repo-assist:issue-triage
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
githubnext/gh-cao#20041 ·
Maintainers usually reply within 1 day
All issues in githubnext/gh-cao
Similar issues
-
[ordering-review] workshop order graph: 1 confirmed ordering problem, 3 cycles are false positivesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
githubnext/gh-aw-workshop#5331 ·
Maintainers usually reply within 1 day
-
Remove: 21 SexturyOpenchannels:remove check:passed
Difficulty 1/5 Under an hour Newbie friendliness 65/100
Maintainers usually reply within 4 days
-
[vika] console keeps a stale "in progress" turn after a daemon restart mid-runPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
volcengine/OpenViking#7011 ·
Maintainers usually reply within 1 day
-
__VERSION__ within dist build is not replaced, causes missing version in XDM implementation detailsOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Issue: ready for confirmation Reported on 2.4.9 Triage: Dev.Experience
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
magento/magento2#41773 · 1 comment ·
Maintainers usually reply within 5 days