⚡ Bolt: Use concurrency to filter open PRs

[xbmc4lyfe]

💡 What: We updated _filter_to_still_open_prs in ralph_loop/cli.py to use a ThreadPoolExecutor from concurrent.futures. This allows us to parallelize the subprocess calls made to the GitHub CLI (gh pr view) when we are filtering out already merged PRs.

🎯 Why: Checking each PR sequentially via a new gh subprocess creates a significant bottleneck similar to an N+1 query problem, especially since gh requires making a remote API call, processing the response, and doing local filesystem ops. By running these concurrently, we drastically cut down the wall-clock time required for the fan-out supervisor to determine which PR loops actually need respawning.

📊 Impact: Reduced loop startup time and supervisor fan-out time. A 10x PR fan-out check that took O(N) seconds now runs concurrently (up to 10 workers at a time), effectively converting a sequential O(N) time delay to ~O(N/10), reducing the time delay by up to 90%.

🔬 Measurement:

1. The PR checks can be measured by inserting time.time() prints locally inside _filter_to_still_open_prs or by seeing the logs generated per PR to show the timeline reduction compared to the previous execution.
2. We run the syntax checks python3 -m py_compile codex_ralph_wiggum_loop.py ralph_loop/*.py tests/*.py and PYTHONPATH=. pytest tests/ -k "not test_main_signal_handler".

---

PR created automatically by Jules for task 13060790840254929014 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: 27ba7598-76b3-46f4-8a54-efb41ca15f90

📥 Commits

Reviewing files that changed from the base of the PR and between 7b35ed2 and 30e4f60.

📒 Files selected for processing (2)

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

📜 Recent review details

🔇 Additional comments (5)

.jules/bolt.md (1)

1-3: LGTM!

ralph_loop/cli.py (4)

13-13: LGTM!

---

548-550: LGTM!

---

551-565: LGTM!

---

567-570: LGTM!

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes

  • Improved PR state verification performance by processing multiple checks concurrently rather than sequentially, significantly reducing total execution time when filtering pull requests.

• Documentation

  • Added implementation notes documenting the parallelization approach and performance considerations for independent subprocess operations.

Walkthrough

This PR parallelizes PR open-state checks in _filter_to_still_open_prs by using ThreadPoolExecutor to run independent gh CLI subprocess calls concurrently instead of sequentially, addressing an N+1 performance bottleneck documented in a new optimization note.

Changes

PR State Check Concurrency Optimization

Layer / File(s)	Summary
Performance optimization documentation .jules/bolt.md	A dated learning note documents the N+1 subprocess performance issue and prescribes concurrent execution with result ordering preservation.
Concurrent PR state checking implementation ralph_loop/cli.py	ThreadPoolExecutor is imported; _filter_to_still_open_prs refactors to check PR open-states in parallel via a _check_pr helper, handling CommandError by keeping the PR, and collects results in order via executor.map.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 Swift paws in parallel, a rabbit's delight!
No more one-by-one checks through the night—
ThreadPoolExecutor brings concurrency's grace,
PR state queries now run at full pace! 🏃‍♂️⚡

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: using concurrency (ThreadPoolExecutor) to parallelize PR open-state checks, which is the primary objective of the changeset.
Description check	✅ Passed	The description comprehensively explains the change, its motivation (N+1 bottleneck), expected impact (up to 90% time reduction), and measurement approach, directly relating to the code modifications.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
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/use-concurrency-to-filter-open-prs-13060790840254929014

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch bolt/use-concurrency-to-filter-open-prs-13060790840254929014

---

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