fix: add recovery logic to auto-update cmd_check() for diverged/dirty repos#4245
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe pull request updates the documentation comment in Changes
Estimated Code Review Effort🎯 1 (Trivial) | ⏱️ ~2 minutes Possibly Related PRs
Suggested Labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the stability and efficiency of the system's auto-update and worker management components. It resolves critical issues where the auto-updater could get stuck due to Git repository inconsistencies or API rate limits, ensuring more reliable updates. Concurrently, it introduces a sophisticated mechanism to identify and manage 'thrashing' workers, optimizing resource utilization and preventing unproductive computational cycles. Highlights
Changelog
Ignored Files
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces two main improvements. First, it enhances the auto-update script's robustness by adding recovery logic for diverged or dirty git repositories and by using authenticated GitHub API calls to prevent rate-limiting issues. This makes the auto-update process more resilient. Second, it implements a new 'zero-commit thrash' detection mechanism in the worker watchdog to identify and terminate worker processes that are consuming resources without making progress. While the changes are sound, I've identified a minor issue in the user-facing notification for the new thrashing guardrail, which could lead to confusion. My feedback includes a suggestion to address this.
| ${destination_text} | ||
|
|
||
| **Retry guidance:** Post a blocker update describing a changed plan (or newly unblocked dependency), then move the issue back to \`status:available\` before re-dispatch. |
There was a problem hiding this comment.
The 'Retry guidance' is currently included in all kill notification comments. However, this guidance is specific to thrash kills that result in a status:blocked label. For other kill reasons (idle, stall, runtime), the issue is moved to status:available, making the guidance to 'move the issue back to status:available' confusing and redundant.
To improve clarity, the retry guidance should only be displayed when the kill reason is thrash.
| ${destination_text} | |
| **Retry guidance:** Post a blocker update describing a changed plan (or newly unblocked dependency), then move the issue back to \`status:available\` before re-dispatch. | |
| ${destination_text}$([[ "$reason" == "thrash" ]] && printf '%s' "\n\n**Retry guidance:** Post a blocker update describing a changed plan (or newly unblocked dependency), then move the issue back to \`status:available\` before re-dispatch.") |
|
Worker killed after 1h49m with 0 commits (struggle_ratio: 2141).
|
|
Dispatching worker.
|
alex-solovyev
force-pushed
the
bugfix/auto-update-ff-only-recovery
branch
from
21cd837 to
c6fbc99
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Thu Mar 12 22:37:11 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
… repos Port safeguards from cmd_update() (aidevops.sh) into cmd_check() (auto-update-helper.sh) to prevent indefinite update failures: 1. Ensure on main branch before pull (handles detached HEAD) 2. Clean dirty working tree before pull (git reset + checkout) 3. Fall back to git reset --hard origin/main when ff-only fails 4. Use authenticated gh api for version checks (5000 req/hr vs 60) Root cause: 130+ failed pulls and 106 remote=unknown errors logged over weeks because cmd_check() had no recovery path — it just retried the same failing git pull --ff-only every 10 minutes. Closes #4142
alex-solovyev
force-pushed
the
bugfix/auto-update-ff-only-recovery
branch
from
c6fbc99 to
a7364f5
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Thu Mar 12 22:40:31 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Addresses Gemini review suggestion on PR #4245: the 'Retry guidance' text was shown for all kill reasons (idle, stall, runtime, thrash). For non-thrash kills the issue moves to status:available, making the guidance to 'move back to status:available' confusing and redundant. Now the retry guidance is conditionally appended only when reason == thrash.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
Completed via PR #4245.
|
1 participant
Summary
cmd_update()(aidevops.sh) intocmd_check()(auto-update-helper.sh) to prevent indefinite update failuresgh apias primary version check method (5000 req/hr vs 60 unauthenticated)Problem
auto-update-helper.sh checkusesgit pull --ff-onlybut has no recovery when the working tree is dirty or the branch has diverged. Logs showed 130+ failed pulls across multiple version ranges (stuck for 3-30+ hours each time) and 106 "remote=unknown" errors from unauthenticated API rate limiting.The manual
aidevops updatecommand already handles both failure modes correctly — this PR ports that logic to the auto-updater.Changes
cmd_check()recovery (lines 1067-1110)git reset HEAD -- .+git checkout -- .(install dir, local changes are never intentional)git reset --hard origin/mainwhen--ff-onlyfails (mirrorscmd_update())get_remote_version()authenticated fallback (lines 304-345)gh api(authenticated, 5000 req/hr) — newcurl+jq(60 req/hr) — existingraw.githubusercontent.comCDN fallback — existingVerification
bash -nsyntax check: passshellcheck: clean (only SC1091 info for external source)cmd_update()implementation (aidevops.sh:656-718)References
Closes #4142
Summary by CodeRabbit