⚡ Bolt: Use concurrency to evaluate PR open states

[xbmc4lyfe]

💡 What: The optimization parallelizes the sequential execution of _pr_is_still_open inside _filter_to_still_open_prs using Python's concurrent.futures.ThreadPoolExecutor and executor.map.
🎯 Why: _pr_is_still_open performs a subprocess call to gh pr view, which is a network/CLI boundary bottleneck. When filtering an array of PRs, checking them sequentially causes an O(N) performance delay (the N+1 query problem, but for a CLI/API).
📊 Impact: Checking the state of 10 PRs now takes approximately the time of checking 1 PR. This drastically reduces supervisor wait time.
🔬 Measurement: Verify by running the application against a base with several open PRs and observing the time taken to evaluate the active PR array compared to before.

I have also recorded this learning in .jules/bolt.md.

---

PR created automatically by Jules for task 11812928973526175996 started by @xbmc4lyfe

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a28b42f7-92aa-4219-b58f-1870423e5130

📥 Commits

Reviewing files that changed from the base of the PR and between 7b35ed2 and 0d067e5.

📒 Files selected for processing (2)

• .jules/bolt.md
• ralph_loop/cli.py

📜 Recent review details

🔇 Additional comments (2)

.jules/bolt.md (1)

1-3: LGTM!

ralph_loop/cli.py (1)

5-5: LGTM!

Also applies to: 547-569

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes

  • Resolved a significant performance bottleneck when validating the status of multiple pull requests. Status checks are now processed concurrently rather than sequentially, dramatically reducing wait times and improving responsiveness when handling large batches of pull requests.

• Documentation

  • Added technical documentation detailing the performance optimization improvements and the concurrent processing approach now implemented in the system.

Walkthrough

This PR optimizes PR filtering by replacing sequential status checks with concurrent execution. A performance bottleneck where multiple gh pr view calls block sequentially is fixed by using ThreadPoolExecutor to run checks in parallel, with documentation added to .jules/bolt.md and implementation changes in ralph_loop/cli.py.

Changes

Concurrent PR State Checking

Layer / File(s)	Summary
Performance bottleneck documentation .jules/bolt.md	Documents the identified N+1 query bottleneck from sequential PR status checks and the intended concurrent fix using ThreadPoolExecutor.
Concurrent PR state checking implementation ralph_loop/cli.py	Adds concurrent.futures import and refactors _filter_to_still_open_prs to run PR status checks in parallel while preserving result order, keeping PRs on error and dropping only when confirmed closed, with per-PR outcome logging.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A bottleneck slows the PR flow,
Sequential checks moving oh-so-slow—
Thread pools now run in parallel stride,
Results kept ordered, logic untied!
N+1 solved with concurrent might! ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: using concurrency to evaluate PR open states, which is the primary optimization in the changeset.
Description check	✅ Passed	The description is directly related to the changeset, explaining the what, why, and impact of the optimization, along with measurement guidance and documentation reference.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch bolt-parallel-gh-checks-11812928973526175996

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch bolt-parallel-gh-checks-11812928973526175996

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0d067e56fa

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid spawning rate-limited gh checks in parallel

When a repo has at least 10 fan-out PRs and GitHub responds to these simultaneous gh pr view calls with the secondary rate limit text already handled in _gh_run_with_retry, each worker independently enters the 300s rate-limit sleep/retry loop before _filter_to_still_open_prs can return. That can make the supervisor stall for minutes (or keep retrying in lockstep) before spawning any child, whereas the previous sequential check only had one in-flight request to back off; please gate this fan-out or coordinate rate-limit backoff so concurrency does not amplify secondary limits.

Useful? React with 👍 / 👎.