⚡ Bolt: 병렬 API 호출을 통한 워크플로우 실행 조회 성능 최적화#282
Conversation
|
👋 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
이 PR은 scripts/ci/pr_review_merge_scheduler.py에서 GitHub Actions 워크플로우 실행 조회(queued / in_progress)를 순차 호출하던 로직을 병렬 호출로 바꿔 네트워크 대기 시간을 줄이기 위한 성능 최적화입니다.
Changes:
active_workflow_runs()에서 두 번의gh api호출을ThreadPoolExecutor로 병렬 실행하도록 변경- 작업 계획 문서로 보이는
plan.md파일 추가
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| scripts/ci/pr_review_merge_scheduler.py | queued / in_progress workflow run 조회 REST 호출을 병렬화해 wall-clock latency를 줄임 |
| plan.md | 변경 계획/검증 절차를 문서화하되, 현재는 패치/충돌 마커가 포함된 상태로 추가됨 |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # ⚡ Bolt: Fetch queued and in_progress runs concurrently to avoid sequential API blocking | ||
| # Impact: Halves network wait time by performing two independent REST API requests simultaneously | ||
| with concurrent.futures.ThreadPoolExecutor(max_workers=2) as executor: | ||
| for run_list in executor.map(fetch_runs_by_status, ("queued", "in_progress")): | ||
| runs.extend(run_list) |
| 2. **Implement:** | ||
| Update `scripts/ci/pr_review_merge_scheduler.py`: | ||
| ```python | ||
| <<<<<<< SEARCH |
| ) | ||
| runs.extend(payload.get("workflow_runs") or []) | ||
| return runs | ||
| ======= |
| runs.extend(run_list) | ||
|
|
||
| return runs | ||
| >>>>>>> REPLACE |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull request overview
OpenCode reviewed the current-head evidence but found unresolved reviewer or review-agent threads before approval.
Findings
1. HIGH .github/workflows/opencode-review.yml:1 - Unresolved reviewer thread blocks automated approval
- Problem: OpenCode reached an APPROVE control result, but the approval step found unresolved, non-outdated human or review-agent thread evidence on the current pull request.
- Root cause: Reviewer and review-agent feedback can arrive after bounded model evidence is prepared, so the approval step must re-query GitHub immediately before publishing an approval.
- Fix: Address or resolve the listed reviewer thread(s), then re-run OpenCode on the current head.
- Regression test: Keep the approval gate querying reviewThreads(first: 100) after model output and before create_pull_review APPROVE, including bot review agents other than OpenCode itself.
Review thread evidence
Latest unresolved reviewer thread evidence
scripts/ci/pr_review_merge_scheduler.py line 1308
- Latest reviewer comment: @copilot-pull-request-reviewer at 2026-07-01T17:43:19Z
- Comment URL: #282 (comment)
- Comment excerpt: 'active_workflow_runs()' now performs its REST calls concurrently, but there is no direct unit test asserting it calls the GitHub API for both statuses and correctly aggregates the returned 'workflow_runs'. Adding a focused test would help catch regressions (e.g., wrong status parameter, aggregation mistakes, or concurrency-related refactors).
plan.md line 8
- Latest reviewer comment: @copilot-pull-request-reviewer at 2026-07-01T17:43:20Z
- Comment URL: #282 (comment)
- Comment excerpt: This line looks like an unresolved patch/merge marker ("<<<<<<< SEARCH") embedded in markdown. It will render poorly and is easy to misread as an actual merge conflict; consider replacing it with a normal label/comment for the snippet.
plan.md line 30
- Latest reviewer comment: @copilot-pull-request-reviewer at 2026-07-01T17:43:20Z
- Comment URL: #282 (comment)
- Comment excerpt: This "=======" separator is another patch/merge marker inside the code block. Replace it with a normal label so the markdown reads as intentional documentation rather than conflict artifacts.
plan.md line 60
-
Latest reviewer comment: @copilot-pull-request-reviewer at 2026-07-01T17:43:20Z
-
Comment URL: #282 (comment)
-
Comment excerpt: This ">>>>>>> REPLACE" marker is also a patch/merge artifact in the markdown code block. Replace it with a normal terminator/comment (or remove it as part of cleaning up the snippet) so the document doesn’t look like it contains unresolved conflict markers.
-
Result: REQUEST_CHANGES
-
Reason: unresolved reviewer or review-agent thread(s) were present before approval.
-
Head SHA:
345a2947646eb35f1c280d3f4f0cd7f0b4440860 -
Workflow run: 28536479732
-
Workflow attempt: 1
Changed-File Evidence Map
flowchart LR
PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
Evidence --> S1["Changed file: plan.md"]
S1 --> I1["repository behavior"]
I1 --> R1["Review risk: Changed file: plan.md"]
R1 --> V1["required checks"]
Evidence --> S2["CI script: pr_review_merge_scheduler.py"]
S2 --> I2["review and security gate shell path"]
I2 --> R2["Review risk: CI script: pr_review_merge_scheduler.py"]
R2 --> V2["bash -n plus Strix self-test"]
OpenCode Review Overview
Pull request overviewOpenCode reviewed the current-head evidence but found unresolved reviewer or review-agent threads before approval. Findings1. HIGH .github/workflows/opencode-review.yml:1 - Unresolved reviewer thread blocks automated approval
Review thread evidenceLatest unresolved reviewer thread evidence
|
💡 What:
scripts/ci/pr_review_merge_scheduler.py의active_workflow_runs함수에서 "queued"와 "in_progress" 상태의 워크플로우 실행 목록을 조회하는 GitHub API 호출을 순차적(sequential)으로 실행하던 것을concurrent.futures.ThreadPoolExecutor를 활용해 병렬적(concurrent)으로 실행하도록 최적화했습니다.🎯 Why: 기존에는 2개의 독립적인 API 호출이 N+1 형태로 순차 실행되어 네트워크 블로킹과 실행 지연이 발생했습니다.
.jules/bolt.md의 학습 노트에 명시된 "Avoid N+1 API blocking in PR checks" 철학을 적용하여 스크립트의 성능 병목을 제거하기 위함입니다.📊 Impact: 각 PR 리뷰 및 워크플로우 대기 확인 시 해당 함수의 네트워크 API 대기 시간(Wall-clock time)을 최대 50% 단축시킵니다.
🔬 Measurement: 워크플로우 디스패치 및 조회 로그의 소요 시간 확인 및 전체 CI 리뷰 스크립트 실행 시간을 측정하여 최적화 효과를 검증합니다.
PR created automatically by Jules for task 13844943145212856775 started by @seonghobae