Repository navigation
fix(actions): remove duplicate queue hygiene from the organization sweep #1796
Description
문제
조직 스윕은 각 저장소에서 스케줄러 본체가 끝난 뒤 다시 다음 API를 호출합니다.
- 열린 PR 전체
- 기본 브랜치 HEAD
queuedActions 실행 전체in_progressActions 실행 전체- 선택된 실행의 재검증·취소
이 호출들은 교차 저장소 GitHub App 설치 토큰의 공유 한도를 사용합니다. 반면 보호된 main에는 이미 current-head-run-coalescer가 있고, 대상 저장소의 github.token으로 repository + PR 번호 단위의 현재 HEAD 재검증과 구형 실행 정리를 수행합니다. 같은 책임을 조직 스윕이 다시 수행하면서 API 한도와 Actions 부팅 작업을 늘리고 있습니다.
이 중복은 PR #1245의 미해결 리뷰 지적과도 직접 연결됩니다. 스케줄러 본체가 성공한 뒤 queue-hygiene 호출에서 설치 토큰 한도가 소진되면 스윕은 다음 저장소로 계속 진행할 수 있습니다.
권위 경계
- 같은 PR의 구형 실행 취소:
current-head-run-coalescer - 리뷰·수정·병합 상태 전이:
pr-review-merge-scheduler - 기본 브랜치·수동·고아 실행 정리: 필요성이 입증되면 별도의 저빈도·유한 예산 owner workflow
- 조직 스윕: Actions 전체 실행 목록을 저장소마다 다시 읽지 않음
current-head-run-coalescer의 그룹은 다음 형태를 유지해야 합니다.
Current Head Run Coalescer-{repository}-{PR번호}
구형 동일 PR 실행만 정리하며 다른 저장소·다른 PR을 취소하지 않습니다. 리뷰·검증 실행은 stale HEAD를 정리할 수 있지만 release·deploy·migration은 취소 대상이 아닙니다.
TDD 수용 기준
- 먼저 현행 조직 스윕이 저장소마다
/actions/runs?status=queued와/actions/runs?status=in_progress를 읽는 RED 계약을 고정합니다. - 조직 스윕에서 PR 단위 queue-hygiene 블록과
ORG_SWEEP_STALE_QUEUE_HOURS를 제거합니다. current-head-run-coalescer가 대상 저장소github.token, exact live PR HEAD,repository + PR 번호그룹을 사용한다는 계약을 강화합니다.- 동일 PR의 연속 push에서 이전 HEAD 실행만 정리되고, 다른 PR·다른 저장소의 실행은 보존되는 회귀 테스트를 통과시킵니다.
- 기본 브랜치·고아 실행 정리가 실제로 필요한 분모와 사례를 측정합니다. 필요하면 시간별 전체 스윕이 아니라 별도 저빈도 workflow에
maximum repositories,maximum API calls,maximum cancellations예산을 둡니다. - 고정 sleep, 저장소별 중복 Actions inventory, 성공을 가장한 rate-limit 삼키기를 추가하지 않습니다.
- 변경 후
test_strix_quick_gate.sh, queue contract, actionlint, 전체 production statement/branch coverage를 exact head에서 통과시킵니다. - 목적을 마친 source-fix workflow는 같은 검증 커밋에서 제거합니다.
운영 검증
- 변경 전·후 시간당 GitHub API 호출 수
- 조직 스윕 p50/p95 실행시간
startup_failure,runner_id=0, pending-slot replacement 수- 같은 PR 이전 HEAD의 잔존 시간
- 다른 PR 실행의 오취소 0건
협업 지시
여유가 있는 로컬 세션은 이 이슈의 독립 작업을 맡고, exact head·실패 로그·수정 전 RED·수정 후 GREEN을 이 이슈에 남겨 주십시오.
기다리는 동안 다른 로컬 세션에게 지속적으로 지시 받아 도우세요. 계속 묻고 계속 피드백하고 계속 지원하세요. 더 주도적이고 더 적극적으로요.
현재 작업자는 #1245의 rate-limit deferral을 선행 완화로 처리하되, 이 이슈가 중복 queue-hygiene 제거의 canonical successor입니다.
Activity
fix(scheduler): defer shared installation rate limits (#1245)
chore(actions): bootstrap verified #1796 source repair
seonghobae commentedon Sep 3, 2026
첫 실행 증거 — source-fix 시작 단계 실패
임시 writer commit
40794dc4765f400929fabc6b5d777b6dc155e6ff에서 run33761818467이 생성됐지만 같은 초에failure로 끝났고, Actions Jobs API는 job 0개를 반환했습니다. checkout·설치·테스트·수정 단계는 하나도 실행되지 않았습니다.이는 제품 테스트 RED와 다릅니다. 현재
.github#1150이 구분하는startup_failure_before_job_materialization사례와 같은 관측 형태입니다. 따라서 이 실행을 구현 실패나 검증 완료로 해석하지 않습니다.조치:
진척 상태: #1245 선행 완화는 병합됐지만 #1796의 중복 owner 제거는 아직 미구현입니다.
chore(actions): retire failed #1796 source writer
seonghobae commentedon Sep 3, 2026
병합된 #1245의 잔존 결함 분리 및 병렬 소유
#1245 병합본을 다시 읽었습니다.
gh_graphql()과gh_api_json()은 shared installation rate-limit 403에서도 최대 4회 시도하며 각 재시도 사이time.sleep()을 수행합니다. 단일 API 호출에서 최대 약 180초를 runner가 점유할 수 있다는 독립 세션의 finding이 병합 전 이미 재현됐지만, 현재main@232107a0b6235efaa4a221a41443c436eac3dd00에 그대로 들어갔습니다.제가 충돌을 피하기 위해 이 이슈의 no-sleep focused successor lane을 맡겠습니다.
GET /rate_limit추가 호출과 reset-time 계산 제거time.sleep0회 RED/GREEN 고정다른 로컬 세션은 이와 겹치지 않는 duplicate queue-hygiene removal lane을 맡아 주세요.
/actions/runs?status=queued|in_progressinventory와ORG_SWEEP_STALE_QUEUE_HOURS제거current-head-run-coalescer의 repo-local token/current live head/repository+PR 책임 강화서로 PR을 연 뒤 상대 PR의 exact head를 독립 리뷰하고 피드백을 주고받겠습니다.
seonghobae commentedon Sep 3, 2026
ConceptWeave consumer canary — refreshed 2026-09-04 against protected control-plane
main@c129aeb47bb5fbecebcfdbd0b94d7d31f41dee85:ConceptWeave#1@a8b95a3ab336986fd8e3da6b5a9f267cbf08a253: Product33865020185, job100997794186, exact current head, explicitubuntu-24.04, queued before runner assignment withrunner_id=0and zero steps. Exact repository-state inspection deterministically established that the strengthened research-reference contract was unsatisfied before the minimal bibliography repair, but no hosted RED is claimed; the repaired head remains non-terminal.ConceptWeave#5@67c104987e54b39e4c9a9ecae803306f9a6ab645: Product33865125357, job100998123088, exact current head, explicitubuntu-24.04, queued before runner assignment withrunner_id=0and zero steps. Two non-force Foundation restacks changed only inherited bibliography/baseline docs; the Client semantic delta remains intact.ConceptWeave#6@a0197ba18a48906ca9830a2d2953facb21158b53: Product33865153034, job100998209983, exact current head, explicitubuntu-24.04, queued before runner assignment withrunner_id=0and zero steps. The registry-identity semantic RED has still not executed.Intervening central work is adopted, not treated as a race. Protected main includes #1847's empty-PR cleanup consolidation and #1848's OpenCode concurrency-contract synchronization. Two fresh sweep reads moved queued inventory
226 -> 225; a later read rose to237as new #1849 workflow traffic entered the queue. This is queue churn, not consumer GREEN or regression proof by count alone, because all three ConceptWeave canaries stayed pre-runner throughout.Acceptance remains real runner assignment + exact checkout + terminal evidence on exact current heads. Do not ask the consumer repository to no-op push, weaken gates, self-approve, admin-bypass or recreate cross-repository cancellation.
seonghobae commentedon Sep 3, 2026
Fresh ConceptWeave consumer evidence for this queue-hygiene owner boundary: current protected
.github/mainis07d9ec23fb265c76539d23249e1dfa124ea7b23b, while the queue-health implementation PR #1150 remainsbbacf9e81ae954eb8365fbfe1856d8698a768a4aon recorded base8c085835fbf77de2321b72fa6b8dd946227e523eand therefore still needs non-force current-main adoption before its evidence is current.Unchanged ConceptWeave Product jobs remain blocked before source execution: #5
33741224641/100603361888, and #633760465773/100665220457(ubuntu-24.04,runner_id=0,steps=[]). Foundation Required OpenCode attempt 2 further shows selective admission inside one run: job100733416054is pre-runner queued while cleanup/bootstrap/coverage siblings acquired hosted runners and succeeded. This is consistent with preserving #1796's narrow goal: remove duplicate organization-sweep Actions inventory/API pressure without moving same-PR stale-run retirement out ofcurrent-head-run-coalescer, and then revalidate unchanged consumers. No ConceptWeave source churn or gate weakening was used.seonghobae commentedon Sep 3, 2026
Fresh 2026-09-04 KST ConceptWeave consumer evidence for the queue-hygiene owner boundary:
.github/main@8e7e985d00694302b3f3a7db6bd3ff0d82e46ca5. Relevant protected lineage now includes fix(opencode): break runner-capacity dispatch deadlock #1823–ci(quality): isolate PR concurrency by repository #1827, merged ci: retire duplicate PR security workflows #1833 (live required-workflow OSV/Scorecard consolidation), and merged ci(security): consolidate PR Gitleaks scanning #1834 (central PR Gitleaks hard gate consolidated into Security Scan while non-PR Secret Scan backstops remain).osv-scanandscorecardare jobs inside the bundled Security Scan and must not be miscounted as standalone organization-required workflow entries..githubqueued inventory: about 1,007. This is materially below the earlier ~1,906 peak but above the ~900 post-recovery readings, so aggregate count alone is not stable-admission GREEN.0029b5ef8005fda9075a575a49bd8efb7b437aa7on base8e7e985.... A fresh CI-path audit found a separate real defect: prior test-only heads could never record the intended owner RED because no matching quality workflow path includedtests/test_org_sweep_queue_hygiene_owner.py; the only workflow that executes the completepytest testsgate is path-filtered to its own trusted-uv bounded files.0029b5ef...adds only a dedicated exact-headqueue-ownership-quality-ci.ymlwith repository-qualified concurrency, read-only permissions, pinned actions and hash-verified pytest. Scheduler/coalescer production behavior is still unchanged. Waiting on the earlier heads therefore was not valid TDD progress.e1b0eaa544c92f3526d91c33d50e11d17115a5cf; Product33836138430/100908944398is still queued before steps.30fdde3746f023a2fab010bcb0b46e670ded0b6e; Product33836434482/100909811550is still queued before steps.774984667d36e7d27bb7d8d4f76f50fa8f1dad09; Product33836442606/100909835310is still queued before steps.Do not cancel or retrigger unchanged ConceptWeave canaries. Let the new #1821 exact-head quality lane produce the real queue-owner RED, apply only the smallest central causal repair, then re-read these exact consumer heads before creating new leaf evidence. No force push, destructive rebase, self-approval or gate weakening.
seonghobae commentedon Sep 3, 2026
Fresh unchanged-head acceptance read after the prior 1,687-run snapshot:
.githubprotectedmainis still07d9ec23fb265c76539d23249e1dfa124ea7b23b.ConceptWeave#5@1e543bbcc343adad04b748109cdd2a22b0d49f1eProduct33741224641/ job100603361888remainsubuntu-24.04,runner_id=0,steps=[].ConceptWeave#6@c9af2255fb721b8e05e608e6b2525017b1f59151Product33760465773/ job100665220457remainsubuntu-24.04,runner_id=0,steps=[].opencode-reviewjob100733416054is pre-runner queued, while cleanup/bootstrap/coverage siblings in the same run are terminal-success on real hosted runners. Foundation Strix similarly has successful changed-scope/cleanup siblings while actualstrixjob100786678387is now the queued no-runner boundary.Interpretation: the reduction in aggregate queue depth is useful but is not yet owner GREEN. It strengthens the need to validate #1796 by unchanged consumer runner assignment and exact checkout, not by queue-count reduction alone. Keep the duplicate organization-sweep inventory/API-pressure repair narrow; do not cancel the sole current-head Product evidence or ask ConceptWeave to retrigger.
seonghobae commentedon Sep 3, 2026
2026-09-04 fresh consumer evidence from
ContextualWisdomLab/ConceptWeave: the.githubrepository-wide queued Actions inventory has rebounded to 1739 runs (GET /repos/ContextualWisdomLab/.github/actions/runs?status=queued&per_page=1), after the immediately preceding ConceptWeave sweep had observed the backlog near 1604. This is not monotonic recovery.At the same time, ConceptWeave continues to reproduce selective old-lane starvation without leaf churn:
fa0e31272097d154427ac53bfb7cc60dc96e72c8: Product run33814440715, job100843333180, explicitubuntu-24.04,runner_id=0,steps=[].c9af2255fb721b8e05e608e6b2525017b1f59151: Product run33760465773, job100665220457, explicitubuntu-24.04, still pre-runner queued.100603361888previously waited ~12h before acquiring a hosted runner and reaching a genuine repository RED with no selector/source workaround, so long queue age alone does not justify leaf retriggers.Please treat the 1739 rebound as acceptance evidence for this owner boundary: remove duplicate organization-sweep queued/in-progress inventory and measure post-change total queued count/API call rate, but preserve sole current-head evidence lanes and do not convert
runner_id=0into success or consumer-side no-op churn.seonghobae commentedon Sep 4, 2026
ConceptWeave consumer sweep (2026-09-04): central queued Actions inventory is now 1,722 runs on protected
.github/main@07d9ec23fb265c76539d23249e1dfa124ea7b23b(freshstatus=queued&per_page=1total_count), down from the previous ConceptWeave observation of 1,739 but still above the earlier ~1,604 trough. Leaf evidence remains unchanged: ConceptWeave Client Product33814440715job100843333180(fa0e312...) and Source Observation Product33760465773job100665220457(c9af2255...) are both explicitubuntu-24.04,runner_id=0,steps=[], so no leaf rerun/no-op commit was generated. Acceptance remains actual queue-pressure reduction that allows unchanged exact-head substantive lanes to acquire runners, not merely aggregate backlog movement.seonghobae commentedon Sep 4, 2026
Successor correction to the earlier ConceptWeave consumer note: PR #5 legitimately advanced for a verified docs-to-live-state repair to exact head
cd99eb4a42011206f8efa376106aa4b121d2010e; its new automatically created Product33822984126/ job100869494950is pre-runner queued onubuntu-24.04withrunner_id=0andsteps=[]. Treat the earlierfa0e312...job as historical rather than a current leaf. PR #6 remains unchanged atc9af2255.../ job100665220457, also pre-runner queued. No duplicate rerun or no-op trigger was created.seonghobae commentedon Sep 7, 2026
현재 소스와 기존 삭제 근거 연결
현재 main
c9052e607e5f3cc76e73207e7786b21500721b79의 workflow 목록·scheduler 본문과 경로별 commit history를 직접 조회했습니다. 조직 스윕 삭제는 이미 #1878 / 1b65dbc에 반영됐습니다. 이후85f4ef926feed08cf502a8e6bf26e495a0bb7bed가 head coalescing을 scheduler 안으로 통합했습니다. 현재 scheduler에는 대상 PR용 current_head_run_coalescer 호출이 있지만 옛 org-queue-sweep job은 없습니다. 삭제 구현을 중복해서 만들 필요는 없습니다.다만
docs/doctoring/org-queue-sweep-rotation.md는 아직 15분 조직 순회, persistent rotation counter, rate-limit 재시도 sleep을 현재 동작처럼 설명합니다. 현재 코드와 맞지 않는 역사 설명이므로 기존 문서 담당에서 superseded 표시와 #1878/현행 경계를 연결해야 합니다. #1803의 fail-fast 수정 또한 본문에서 중복 inventory 제거와 별개라고 명시했습니다.이 댓글은 소스 삭제·통합의 확인입니다. API 호출량/runner 점유/같은 PR 구형 HEAD 정리/다른 PR 오취소 0건의 운영 전후 증거까지 확인한 것은 아니므로 이 이슈나 전체 항목15를 완료로 닫지 않습니다.
docs(doctoring): mark the org-queue-sweep rotation record historical