GitHub-hosted runner shuts down in 3 attempts (UserCancelled) #212669
Unanswered
luiguiHerrera
asked this question in
Actions
Replies: 1 comment
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
🏷️ Discussion Type
Bug
💬 Feature/Topic Area
ARC (Actions Runner Controller)
Discussion Details
Summary
Three attempts of the same GitHub Actions workflow failed because the GitHub-hosted runner unexpectedly shut down at virtually the same point, without any test failures.
Repository:
luiguiHerrera/Luiguiherrera-webWorkflow run: https://github.com/luiguiHerrera/Luiguiherrera-web/actions/runs/42536568040
Commit:
83d304321a2937713942d908c811d40c15e59847Affected attempts
Attempt | Job ID | Duration -- | -- | -- 1 | 128902060583 | 11m 16s 2 | 128907108347 | 10m 25s 3 | 129200312849 | 12m 38sAttempt 3 was executed with debug logging enabled.
Observed behavior
All three attempts:
Completed 116 Python tests successfully, with no FAIL or ERROR results.
Stopped immediately after
test_wrong_or_extra_parent_rejectedpassed.Interrupted the remaining tests and all subsequent workflow steps.
Ended with the workflow conclusion
failure.The third attempt's diagnostic logs contain:
The process subsequently exited with code 143.
The runner had successfully renewed its job lease shortly before the interruption.
Configuration
GitHub-hosted Ubuntu runners.
Runner version: 2.338.2.
Job timeout: 40 minutes.
No step-specific timeout.
No concurrency cancellation configuration.
No explicit cancellation request identified.
The interruptions occurred well before the configured job timeout.
Investigation performed
The next test class,
ZodSecurityTests, has an initialization step that creates temporary Git fixtures.Its
setUpClass()method was executed independently on macOS and completed successfully in 13.34 seconds, with a measured Python memory peak of 447.6 MiB.This does not reproduce the hosted Linux environment. Resource exhaustion remains unconfirmed.
The
UserCancelleddiagnostic indicates the runner's internal shutdown category, but does not establish that a user manually canceled the workflow.Questions
What might cause a GitHub-hosted runner to receive a
UserCancelledshutdown signal at nearly the same point across three attempts?Is there a known runner orchestration or resource-management issue that could explain this behavior?
What additional diagnostic evidence would help identify the source of the shutdown?
Is there a way to distinguish an infrastructure-initiated shutdown from an external cancellation request?
The root cause remains unknown. We have preserved the debug logs and are avoiding further retries or code changes without evidence of a specific cause.
Any guidance from GitHub engineers or community members would be appreciated.
All reactions