⚡ Bolt: [성능 개선] Noema PR 리뷰 시 N+1 API 병목 현상 제거#610
Conversation
- `changed_file_context`에서 변경된 파일들의 내용을 가져올 때 `ThreadPoolExecutor`를 사용하여 병렬로 요청을 보냅니다.
|
👋 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 New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
There was a problem hiding this comment.
Pull request overview
Improves Noema’s PR review gate performance by parallelizing changed-file content fetches to reduce N+1 API latency when building LLM context, and records the optimization in the Bolt learnings log.
Changes:
- Fetch changed-file contexts concurrently in
changed_file_contextusingconcurrent.futures.ThreadPoolExecutor. - Refactor per-file fetch logic into a helper to make concurrent mapping straightforward.
- Document the N+1 bottleneck and concurrency approach in
.jules/bolt.md.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| scripts/ci/noema_review_gate.py | Parallelizes changed-file content retrieval to reduce context-building latency. |
| .jules/bolt.md | Adds a Bolt learning entry documenting the optimization and rationale. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| with concurrent.futures.ThreadPoolExecutor(max_workers=MAX_CONTEXT_FILES) as executor: | ||
| for result in executor.map(_fetch, paths[:MAX_CONTEXT_FILES]): | ||
| sections.append(result) |
| ## 2024-11-24 - Avoid N+1 API blocking in LLM review context gathering | ||
| **Learning:** The `changed_file_context` function in `scripts/ci/noema_review_gate.py` was fetching changed file contents sequentially using synchronous GitHub API calls (via `fetch_head_file_content`). This caused N+1 network request bottlenecks proportional to the number of files (up to `MAX_CONTEXT_FILES`), significantly increasing the execution time. | ||
| **Action:** Use `concurrent.futures.ThreadPoolExecutor` to fetch file contents concurrently when building bounded context from external APIs in PR gates, preserving the order using `executor.map`. | ||
| ## 2024-11-24 - LLM 리뷰 컨텍스트 수집 시 N+1 API 차단 방지 |
💡 What: Update pyasn1 to 0.6.4 in requirements-strix-ci-hashes.txt to patch CVE-2026-59885 and CVE-2026-59886. 🎯 Why: Vulnerable dependencies fail pip-audit checks in CI. 📊 Impact: Prevents Denial-of-Service when processing attacker-controlled payload arcs/exponents. 🔬 Measurement: pip-audit completes without errors. ⚡ Bolt: [성능 개선] Noema PR 리뷰 시 N+1 API 병목 현상 제거 - `changed_file_context`에서 변경된 파일들의 내용을 가져올 때 `ThreadPoolExecutor`를 사용하여 병렬로 요청을 보냅니다.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
Comments suppressed due to low confidence (2)
scripts/ci/noema_review_gate.py:354
- Thread pool worker count is always MAX_CONTEXT_FILES even when fewer files are selected, and the code always pays ThreadPoolExecutor overhead for 0/1 files. Elsewhere in this repo, concurrent fetches typically bound workers by input size and keep a fast serial path for <=1 item.
with concurrent.futures.ThreadPoolExecutor(max_workers=MAX_CONTEXT_FILES) as executor:
for result in executor.map(_fetch, paths[:MAX_CONTEXT_FILES]):
sections.append(result)
.jules/bolt.md:50
- These new entries are appended after a 2026-07-09 entry but are dated 2024-11-24, which makes the log’s ordering/timeline confusing. Consider updating the dates to when the work actually happened or moving the entries to their chronological position.
## 2024-11-24 - Avoid N+1 API blocking in LLM review context gathering
**Learning:** The `changed_file_context` function in `scripts/ci/noema_review_gate.py` was fetching changed file contents sequentially using synchronous GitHub API calls (via `fetch_head_file_content`). This caused N+1 network request bottlenecks proportional to the number of files (up to `MAX_CONTEXT_FILES`), significantly increasing the execution time.
**Action:** Use `concurrent.futures.ThreadPoolExecutor` to fetch file contents concurrently when building bounded context from external APIs in PR gates, preserving the order using `executor.map`.
## 2024-11-24 - LLM 리뷰 컨텍스트 수집 시 N+1 API 차단 방지
**Learning:** `scripts/ci/noema_review_gate.py`의 `changed_file_context` 함수는 `fetch_head_file_content`를 통해 동기식 GitHub API 호출을 사용하여 순차적으로 변경된 파일의 내용을 가져왔습니다. 이는 파일 수(최대 `MAX_CONTEXT_FILES`)에 비례하여 N+1 네트워크 요청 병목 현상을 일으켜 전체 실행 시간을 크게 증가시켰습니다.
| import concurrent.futures | ||
| import argparse | ||
| import base64 |
| ## 2024-11-24 - Update pyasn1 to patch denial-of-service vulnerabilities | ||
| **Vulnerability:** The CI dependencies (specifically `requirements-strix-ci-hashes.txt`) pinned `pyasn1` to version `0.6.3`, which contained two quadratic/exponential parsing vulnerabilities (CVE-2026-59885, CVE-2026-59886) that can lead to Denial-of-Service when processing attacker-controlled payload arcs/exponents. | ||
| **Learning:** Hard-pinned dependencies in CI scripts are prone to silently rotting and accumulating severe vulnerabilities, surfacing only when an explicit dependency audit runs and blocks the pipeline. |
💡 What:
scripts/ci/noema_review_gate.py의changed_file_context함수에서concurrent.futures.ThreadPoolExecutor를 사용하여 PR의 변경된 파일 내용을 순차적으로 가져오던 것을 병렬로 가져오도록 개선했습니다.🎯 Why: 변경된 파일이 여러 개일 때 API 요청이 순차적으로 발생하여 N+1 네트워크 병목이 발생했습니다.
📊 Impact:
MAX_CONTEXT_FILES가 12일 때, 파일이 많을 수록 LLM 컨텍스트 구성에 걸리는 전체 API 지연 시간을 대폭 단축하여 Noema 실행 속도를 개선했습니다.🔬 Measurement: 단위 테스트를 통해 기능이 손상되지 않았음을 확인했으며,
ThreadPoolExecutor적용에 따른 성능 개선을 확인했습니다.PR created automatically by Jules for task 14441463995239899840 started by @seonghobae