t1038: Reconcile terminal DB states with GitHub issues in pulse Phase 3c#1390
Conversation
Tasks can reach terminal states (cancelled, failed, verified, deployed) via direct DB updates or manual intervention, bypassing cmd_transition and its sync_issue_status_label call. This leaves GitHub issues open when the DB says the task is done. Phase 3c sweeps tasks in terminal states that had recent activity (last 7 days), checks if their GitHub issue is still open, and syncs the state. Runs at most once per 10 minutes to avoid API rate limits. Root cause: t1010 was cancelled via direct DB update, but its GitHub issue #1300 remained open with stale status:verify-failed label. Refs: t1038, GH#1389
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ Finishing touches🧪 Generate unit tests (beta)
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 @marcusquinn, 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 introduces a new reconciliation mechanism to the supervisor script, ensuring that GitHub issue labels accurately reflect the terminal states of tasks in the database. This addresses a discrepancy where direct database updates could bypass the usual synchronization process, leaving GitHub issues with stale status labels. The new phase periodically checks and updates these issues, incorporating a cooldown to manage API usage. Highlights
Changelog
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
|
🔍 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: Fri Feb 13 15:59:27 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
|
![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 a new reconciliation phase (3c) to the supervisor pulse, which is a great addition for ensuring data consistency between the local database and GitHub issues. The implementation is solid, with a cooldown mechanism to prevent API rate limiting and a targeted query to find relevant tasks. My review includes a few suggestions to improve error logging by adhering to the repository's style guide, which will enhance the script's robustness and debuggability.
| SELECT DISTINCT task_id FROM state_log | ||
| WHERE timestamp > datetime('now', '-7 days') | ||
| ) | ||
| ;" 2>/dev/null || echo "") |
There was a problem hiding this comment.
Error output from the db command is being suppressed. According to the repository style guide (line 50), 2>/dev/null should only be used when redirecting to log files, not for blanket suppression. To aid in debugging, please redirect stderr to the supervisor log file.
| ;" 2>/dev/null || echo "") | |
| ;" 2>>"$SUPERVISOR_LOG" || echo "") |
References
- Style guide (line 50) states:
2>/dev/nullis acceptable ONLY when redirecting to log files, not blanket suppression. (link)
|
|
||
| # Find the GitHub issue number | ||
| local rec_issue | ||
| rec_issue=$(find_task_issue_number "$rec_id" "$rec_repo" 2>/dev/null || echo "") |
There was a problem hiding this comment.
Error output from find_task_issue_number is being suppressed. According to the repository style guide (line 50), errors should be logged. Please redirect stderr to the supervisor log file for better debuggability.
| rec_issue=$(find_task_issue_number "$rec_id" "$rec_repo" 2>/dev/null || echo "") | |
| rec_issue=$(find_task_issue_number "$rec_id" "$rec_repo" 2>>"$SUPERVISOR_LOG" || echo "") |
References
- Style guide (line 50) states:
2>/dev/nullis acceptable ONLY when redirecting to log files, not blanket suppression. (link)
| [[ -z "$rec_issue" ]] && continue | ||
|
|
||
| local rec_slug | ||
| rec_slug=$(detect_repo_slug "$rec_repo" 2>/dev/null || echo "") |
There was a problem hiding this comment.
Error output from detect_repo_slug is being suppressed. Per the repository style guide (line 50), errors should be logged. Please redirect stderr to the supervisor log file.
| rec_slug=$(detect_repo_slug "$rec_repo" 2>/dev/null || echo "") | |
| rec_slug=$(detect_repo_slug "$rec_repo" 2>>"$SUPERVISOR_LOG" || echo "") |
References
- Style guide (line 50) states:
2>/dev/nullis acceptable ONLY when redirecting to log files, not blanket suppression. (link)
|
|
||
| # Check if the issue is still open | ||
| local issue_state | ||
| issue_state=$(gh issue view "$rec_issue" --repo "$rec_slug" --json state -q .state 2>/dev/null || echo "") |
There was a problem hiding this comment.
Error output from the gh command is being suppressed. This could hide important issues like authentication failures. As per the repository style guide (line 50), please redirect stderr to the supervisor log file.
| issue_state=$(gh issue view "$rec_issue" --repo "$rec_slug" --json state -q .state 2>/dev/null || echo "") | |
| issue_state=$(gh issue view "$rec_issue" --repo "$rec_slug" --json state -q .state 2>>"$SUPERVISOR_LOG" || echo "") |
References
- Style guide (line 50) states:
2>/dev/nullis acceptable ONLY when redirecting to log files, not blanket suppression. (link)
| fi | ||
| fi | ||
|
|
||
| date +%s >"$reconcile_cooldown_file" 2>/dev/null || true |
There was a problem hiding this comment.
For consistency with logging errors, and to adhere to the style guide (line 50), consider logging potential errors when writing to the cooldown file instead of suppressing them.
| date +%s >"$reconcile_cooldown_file" 2>/dev/null || true | |
| date +%s >>"$reconcile_cooldown_file" 2>>"$SUPERVISOR_LOG" || true |
References
- Style guide (line 50) states:
2>/dev/nullis acceptable ONLY when redirecting to log files, not blanket suppression. (link)
1 participant
Summary
cmd_transitionand itssync_issue_status_labelcall, leaving GitHub issues open with stale labelsstatus:verify-failedRefs: t1038, GH#1389