chore(ci): dependency-review 가 head 스냅샷 제출을 못 기다림 — 2단 파이프라인 경쟁 조건으로 산발 실패 #1081

📜 Overview

PR 의 dependency snapshot 은 두 워크플로로 나뉘어 제출된다 (fork PR 보안 패턴).

1. Gradle Dependency Submission — PR 컨텍스트. 스냅샷을 만들어 아티팩트로 올리기만 한다
2. Submit PR Dependency Graph — workflow_run 으로 default branch 정의로 돌며 그 아티팩트를 API 에 제출한다

Review dependency changes 는 2번이 끝나야 볼 것이 생기는데, 1번과 동시에 출발해 10분만 기다린다(retry-on-snapshot-warnings-timeout: 600). 파이프라인이 그 안에 안 끝나면 취약점과 무관하게 실패한다.

No snapshots were found for the head SHA 6a50a7a768b6b078c255ed3f9f32f92394f14a1d.
Retrying in 10 seconds...

🔍 실측 — PR #886 (2026-08-24, UTC)

workflow_run 트리거 지연과 러너 큐 대기만 5분이 붙는다. 생성 3분 + 지연 5분 + 제출 1분이면 9분을 넘고, 한도는 10분이다. 큐가 조금만 밀리면 넘어간다.

같은 시각 다른 PR(#989·#988·#967·#954·#947)은 전부 pass 였다 — 그때 큐가 한가했기 때문이지 #886 에 문제가 있어서가 아니다. 즉 PR 내용과 무관하게 큐 상태로 결과가 갈린다.

실제로 #886 의 의존성 변경은 0 건이다. .kt 파일만 건드린 PR 이고, compare API 도 그렇게 답한다.

gh api "repos/Afternote/Afternote-FE/dependency-graph/compare/f86ce498...6a50a7a7"
→ 0

🎯 왜 지금 문제가 되나

Run Unit Tests 를 required 로 올리면서(androidTest 미검증 착륙이 #936 → #1022 → #1070 세 번 반복) Review dependency changes 도 함께 올렸다가, 이 경쟁 조건 때문에 되돌렸다.

required 는 "항상 신뢰할 수 있는 신호" 여야 한다. 큐 상태로 산발 실패하는 체크를 required 로 두면 재실행으로 통과시키는 습관이 생기고, 그건 게이트 신뢰를 갉아먹는다 — required 로 올린 취지와 정반대다.

현재 required 8 개: guard · Run Unit Tests · Check Code Quality (Ktlint) · Check Project Issues (Android Lint) · Validate Compose Preview Screenshots · Repository Quality · Analyze (java-kotlin) · Analyze (actions)

🛠 해결 방향

어느 쪽이든 「제출이 끝난 뒤에 검토한다」 를 보장하면 된다.

• A. Review 를 제출 뒤로 옮긴다 — dependency-review 를 Submit PR Dependency Graph 의 workflow_run 체인 뒤에 붙인다. 경쟁 자체가 사라지지만 체크 이름·트리거가 바뀐다
• B. 대기 한도를 늘린다 — retry-on-snapshot-warnings-timeout 을 600 → 1200 등으로. 한 줄이면 되지만 근본 해결은 아니고 큐가 더 밀리면 또 샌다
• C. 제출을 PR 워크플로 안으로 합친다 — 2단 분리를 없앤다. 다만 fork PR 보안 패턴을 포기하게 되므로 권장하지 않는다

고쳐진 뒤 Review dependency changes 를 required 로 되돌린다.

🔗 구분 — 같은 체크의 다른 고장 3종

셋 다 Review dependency changes 가 빨개지지만 고칠 자리가 다르다. #1009 의 correlator 수정(#1011)은 이미 이 브랜치에 들어와 있고, 그것으로는 이 건이 해결되지 않는다.