fix: wipe migrated config files too when clearing dead registrations - #78
Merged
Conversation
The 404 wipe removed .runner/.credentials/.credentials_rsaparams but left
.runner_migrated behind. The runner's IsConfigured() treats .runner_migrated
as a valid config (ConfigurationStore.cs checks either file), so config.sh
refused to re-register while run.sh crashed loading the missing .runner
("Value cannot be null. (Parameter 'configuredSettings')") — an unrecoverable
crash loop, observed on bump-android-nas.local after GitHub pruned its
registration during a long offline stretch.
Wipes now cover the migrated files, clean /actions-runner as well (the
writable layer survives restarts and the upstream persist-back step re-seeds
the persist dir from it), and a preflight pass heals the already-wedged
orphaned-.runner_migrated state left by older images.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR hardens the runner-registration preflight so it can recover from a “wedged” state caused by GitHub Actions runner broker migration files (.runner_migrated / .credentials_migrated) surviving a registration wipe, which can otherwise block re-registration while still causing run.sh to crash-loop.
Changes:
- Add a centralized
wipe_registration()helper that removes both primary and migrated config/credential files. - Extend wipe behavior to also remove the same files from
/actions-runnerto prevent the upstream persist-back step from re-seeding the volume. - Add a preflight healing step that detects and fixes the specific orphaned migrated-config state (
.runner_migratedpresent without.runner).
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
bump-android-nas.localgot stuck in an unrecoverable crash loop after the runner registration it had persisted (agentId=1891) was pruned server-side by GitHub while the host was offline.The preflight from #77 correctly detected the 404 and wiped
.runner,.credentials, and.credentials_rsaparams— but the persist dir also held a.runner_migrated(written by the runner's broker migration), which the wipe doesn't know about. The runner'sIsConfigured()treats the migrated file as a valid config (ConfigurationStore.cs):So
config.shrefused to register ("already configured") whilerun.shcrashed loading the missing.runner(Value cannot be null. (Parameter 'configuredSettings')) — looping forever. The preflight can't recover either, since it gates on.runnerexisting.Fix
.runner_migratedand.credentials_migrated(IsConfigured()/HasCredentials()treat them as equivalent to the primary files)./actions-runner: the container's writable layer survives restarts, and the upstream entrypoint's persist-back step re-seeds the persist dir from it (observed live — deleting the file from the volume alone got it immediately re-created on the next loop iteration)..runner_migratedpresent without.runner) left behind by images with the old wipe, so affected hosts recover on their own once they pull this image.Testing
bash -n+ shellcheck clean..runnerwithoutACCESS_TOKENis left untouched..runner_migratedfrom both the volume and/actions-runner) unstuck the real crash-looping runner on nas.local, which registered fresh and immediately picked up a job.🤖 Generated with Claude Code