chore(config): scale vue/nextjs fetch_limit 200 → 800 (intervention)#36
Merged
rladmsgh34 merged 3 commits intomainfrom Apr 26, 2026
Merged
chore(config): scale vue/nextjs fetch_limit 200 → 800 (intervention)#36rladmsgh34 merged 3 commits intomainfrom
rladmsgh34 merged 3 commits intomainfrom
Conversation
⚠️ This is an intentional intervention for loop-efficacy measurement — not a routine config tweak. Numbers measured before/after this commit are not directly comparable; rule efficacy deltas spanning this point carry confounding risk. Why now - Incremental fetch (PR #34) makes fetch_limit a safety ceiling, not a per-run cost. Steady-state runs only fetch newly merged PRs since last cron, so 800 ≠ 800 calls — it's "fetch up to 800 if cache is cold." - 200 limit covers ~3 weeks of vuejs/core and vercel/next.js activity. 800 covers ~3 months → cluster detection sees longer regression windows, and the labeling sample pool grows ~5× when we revisit classifier tuning. Why shop stays at 300 - gwangcheon-shop is daily, low-volume (~34 total fix PRs over the repo's lifetime). Already saturated; raising shop's limit would re-fetch the same PRs without surfacing new data. Capacity check (estimated, not measured) - Per-cron API calls: ~426 (current) → ~882 (post-scale) - GH_PAT budget 5000/hr → 4118 margin remaining; safe - Workflow duration ~1-2min currently → ~6min projected; well under the 1hr soft limit Verification plan - First post-merge cron: monitor X-RateLimit-Remaining via gh api rate_limit and confirm projection - Watch for analyze.py timeout / OOM on the larger payload (smart- fetch caps the heavy per-PR view calls so the increase is mostly in the cheap pr-list pagination)
…ation Companion to fetch_limit scale-up. PR description claims ~882 calls/cron at 800 limit but it's an estimate — without per-iteration measurement we can't confirm whether the projection holds or where the budget actually goes (smart-fetch vs AI detection vs pr-list pagination). Each matrix iteration now logs gh api rate_limit at start and end. Diff = real consumption for that iteration. With max-parallel:1 the three iterations are clearly attributable in the workflow log. Reads against /rate_limit don't count against the budget itself.
Step 4b (Open target repo PR via peter-evans/create-pull-request) also consumes GH_PAT. Previous end-checkpoint position measured iteration consumption MINUS Step 4b, leaving gwangcheon-shop CLAUDE.md PR creation calls uncounted on cycles where rules actually changed. Moved to the very last position with `if: always()` so the measurement runs even if an earlier step failed — the whole point is to validate the fetch_limit intervention's API budget projection, and partial-run data is still useful. External repos (post_issues=false) skip Step 4b, so their numbers are unchanged. gwangcheon-shop iterations now report a real total.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
왜 안전한가
Incremental fetch (PR #34) 덕분에 fetch_limit는 cost가 아니라 안전 ceiling. steady-state cron은 cache
generated_at - 14d이후만 fetch → 800 ≠ 800 호출 ("최대 800까지, 캐시 비면").운영 영향 추정 (실측 아님)
GH_PAT 공유 점검
.github/workflows/내GH_PAT사용 워크플로우:evolve-rules.yml단독 (다른 워크플로우 컨텐션 없음)rladmsgh34/gwangcheon-shop의notify-ai-analyzer.yml이 동일 PAT 사용 — but PR-merge dispatch당 단일 curl 1회라 호출량 무시 수준이 시점 이후
compute_effectiveness결과는 정책 변경의 영향과 분리 불가. baseline 비교 시 PR 머지 SHA 기준으로 before/after 따로 봐야 함. 1주 후 본인이 "fix_rate 갑자기 왜?" 할 때 이 PR 가리키는 git log에서 답.Rate-limit 측정 인프라 (보강)
같은 PR에 rate_limit checkpoint 2개 step 추가 — 매트릭스 iteration 진짜 시작/끝 직후
gh api rate_limit로 remaining 로깅. delta = 실제 소비량.checkpoint 위치 정정: end checkpoint를 Step 4b (Open target repo PR, peter-evans/create-pull-request via GH_PAT) 이후로 이동 +
if: always()부착. 이전 위치는 gwangcheon Step 4b 호출이 측정에서 누락됐음.롤백 조건
다음 중 하나라도 발생 시 즉시 롤백 (config/repos.json fetch_limit를 200으로 되돌리는 단일 PR):
record_new_rules로 새 rule 추가되는 빈도 기준. 정상 범위는 cron당 05건이므로 weekly cron 2회 + daily cron 7회 = 최대 9 cron × 5 = 45건이 이론 상한. 실측 normal은 주 510건. 15건 초과면 noise 수준.Test plan
pytest tests/test_repos_config.py— 8/8 통과 (fetch_limit ≤1500 검증 포함).github/workflows/GH_PAT 사용 워크플로우 점검 (evolve-rules.yml 단독)Out of scope
🤖 Generated with Claude Code