⚡ Bolt: Use concurrency to eliminate N+1 latency in PR open-state checking

[xbmc4lyfe]

💡 What: Refactored _filter_to_still_open_prs to use concurrent.futures.ThreadPoolExecutor and executor.map to check PR states concurrently, while preserving original order.
🎯 Why: When the supervisor manages many PRs, checking the state of each PR sequentially via a gh pr view subprocess call causes an N+1 execution delay that limits throughput and degrades startup/fan-out speeds.
📊 Impact: Reduces execution time for _filter_to_still_open_prs from O(N) where N is number of open PRs, down to roughly O(N/10) by executing 10 subprocesses simultaneously.
🔬 Measurement: Inspect application logs for the PR filtering step; total elapsed time for confirming N PR open states will be drastically reduced compared to prior sequential execution. Tests have been run and confirm that sequential order and error handling behavior are fully preserved.

---

PR created automatically by Jules for task 17550946472060673186 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: f8d02534-d6a0-4c5c-a63a-22995bd31b99

📥 Commits

Reviewing files that changed from the base of the PR and between 7b35ed2 and 75ff582.

📒 Files selected for processing (2)

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

📜 Recent review details

🔇 Additional comments (3)

.jules/bolt.md (1)

1-3: LGTM!

ralph_loop/cli.py (2)

3-3: LGTM!

---

547-570: LGTM!

---

📝 Walkthrough

Summary by CodeRabbit

• Documentation

  • Added performance optimization guidance for concurrent PR state checking.

• Refactor

  • Improved PR filtering performance by checking multiple pull request states concurrently instead of sequentially.

Walkthrough

The PR optimizes PR liveness filtering by replacing sequential GitHub CLI state checks with concurrent execution using ThreadPoolExecutor. A performance note documents the N+1 bottleneck approach; the implementation adds the necessary import and refactors the filtering loop to check multiple PRs in parallel.

Changes

PR State Filtering Optimization

Layer / File(s)	Summary
Performance approach documentation .jules/bolt.md	A new dated entry (2026-05-31) describes the N+1 performance bottleneck of sequential gh pr view subprocess calls and prescribes concurrent execution with ThreadPoolExecutor to avoid delays while maintaining result order.
Concurrent PR state checking implementation ralph_loop/cli.py	Imports concurrent.futures and updates _filter_to_still_open_prs to replace sequential per-PR _pr_is_still_open calls with a ThreadPoolExecutor-based concurrent check. Error handling is preserved: failed checks retain the PR with a log message, and confirmed closed PRs are skipped with a skip log.

Estimated Code Review Effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 Sequential checks once caused delays,
But threading swoops through in shorter days,
The PRs are checked both swift and sound,
Concurrency wins—no bottlenecks found! ✨

🚥 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 directly and accurately summarizes the main change: using concurrency to eliminate N+1 latency in PR open-state checking.
Description check	✅ Passed	The description is fully related to the changeset, providing clear context about what was changed, why it was necessary, and the expected performance impact.
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-concurrent-pr-check-17550946472060673186

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch bolt-concurrent-pr-check-17550946472060673186

---

_{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: 75ff5826c1

ℹ️ 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 making startup PR checks uncancellable

When a user interrupts fan-out during this initial open-state filter, the supervisor's SIGINT/SIGTERM handlers have not been installed yet, and ThreadPoolExecutor.__exit__ waits for queued work to finish. Because executor.map queues the full pr_numbers iterable, a Ctrl-C can still leave Ralph running every pending gh pr view check (including retry sleeps) before it exits, which is a regression from the prior sequential loop that stopped at the interrupted command.

Useful? React with 👍 / 👎.