Queue delay invalidates its own dispatches: base_sha equality fails 12 of 16 validate-pr-metadata runs

[seonghobae]

opencode-review-dispatch.yml의 메타데이터 검증이 큐 대기 시간 때문에 실패합니다. 대기가 길수록 실패율이 오르고, 실패가 재시도를 부르고, 재시도가 대기를 늘리는 자기강화 구조입니다.

#1927·#1929(낡은 인가 변수)와 독립된 원인이고, 그쪽을 고쳐도 남습니다. 수정 대상이 설정 값이 아니라 검증 의미론이라 별건으로 올립니다.

측정

opencode-review-dispatch.yml의 실패 run 중 actor=github-actions[bot]인 것(= 인가를 통과하는 신원) 44건 전수를 의존 순서로 재분류했습니다. 스텝을 run 간에 합산하면 하류 캐스케이드가 중복 계산되므로, validate-pr-metadata → coverage-source-tree → coverage-evidence → opencode-review에서 처음 실패한 job을 근본 원인으로 잡았습니다.

16  validate-pr-metadata | Bind workflow inputs...        36%
14  coverage-evidence    | Measure test and docstring     32%   ← #1883 이 해소
 6  opencode-review      | Wake exact-head required...    14%
 8  나머지 (각 1~2건)

최대 원인 16건을 ##[endgroup] 이후의 실행 출력만 읽어 다시 갈랐습니다. 그 앞은 스크립트 소스 에코라 모든 에러 문구를 포함하고 있어서 어떤 가설이든 확증됩니다.

9  repository_dispatch metadata does not match the live pull request: base_sha
3  rejected closed, missing, or malformed live metadata   (state=closed)
4  repository_dispatch authorization rejected             (#1927/#1929)

12/16이 큐 지연의 결과입니다.

실제 로그

Authorized repository_dispatch actor=github-actions[bot] sender=github-actions[bot]   ← 인가 통과
##[error]... does not match the live pull request: base_sha.
  supplied_base=main/76969152...   live_base=main/5d55a31e...
  supplied_head=...fd964d24        live_head=...fd964d24                              ← head 는 일치

head는 맞고 base만 어긋납니다. 디스패치는 보낸 시점의 base SHA를 싣는데, 큐에서 기다리는 동안 main이 전진합니다. state=closed 3건도 검증 도달 시점에 PR이 이미 닫힌 것이라 같은 기전입니다.

드리프트가 사실상 확정적입니다

오늘 origin/main의 시간당 커밋 수입니다.

09시 2 · 10시 2 · 11시 6 · 13시 5 · 14시 6 · 17시 11 · 18시 3 · 19시 1

그리고 실측된 완주 실행 하나가 **총 15시간 37분, 그중 실제 계산 약 73초(대기 99.87%)**였습니다. 시간당 1~11회 움직이는 브랜치에서 15시간을 기다리면 base가 안 움직일 확률은 사실상 0입니다.

핵심: 이 검사는 데이터 의존이 아니라 staleness 정책입니다

opencode-review-dispatch.yml의 실제 데이터 경로입니다.

:186  검증   [ "$SUPPLIED_BASE_SHA" = "$live_base_sha" ] || mismatches+=("base_sha")   ← 불일치면 exit 1
:199  출력   printf 'base_sha=%s\n' "$live_base_sha"                                    ← live 를 내보냄
:295  소비   PR_BASE_SHA: ${{ needs.validate-pr-metadata.outputs.base_sha }}
:332         git -C "$fetch_dir" checkout --detach "$PR_BASE_SHA"

SUPPLIED_BASE_SHA는 비교에만 쓰이고 버려집니다. 하류가 실제로 체크아웃하는 값은 live_base_sha입니다. 즉 supplied와 live가 달라도 파이프라인은 live로 정상 동작합니다.

동등성 요구가 지키는 것은 "디스패치 시점과 검증 시점 사이에 base가 안 움직였다"는 보장이고, 현재 조건에서 그 보장은 거의 항상 거짓입니다.

head_sha는 다릅니다. :188에서 같은 방식으로 비교하지만, 그건 "이 리뷰가 디스패치된 바로 그 커밋을 대상으로 한다"는 exact-head 규율의 근간입니다. head는 엄격히 유지되어야 합니다.

판단이 필요한 지점

base_sha 동등성을 푸는 것이 기술적으로 안전하다는 것까지가 측정으로 말할 수 있는 전부입니다. 남는 질문은 설계입니다.

• base 드리프트를 허용하면 coverage가 디스패치 당시와 다른 base에서 측정됩니다. 그 차이가 판정에 영향을 주는지는 이 리포의 커버리지 계약이 정할 문제입니다.
• 대안으로 허용 범위(예: live base가 supplied base의 후손이면 통과)를 두면 보장을 완전히 버리지 않고 드리프트를 흡수할 수 있습니다.

어느 쪽이든 신뢰 경계에 관한 결정이라 근거만 올립니다.

재현

R=repos/ContextualWisdomLab/.github/actions
gh api "$R/workflows/opencode-review-dispatch.yml/runs?status=failure&per_page=100" \
  --jq '.workflow_runs[] | select(.actor.login=="github-actions[bot]") | .id'
# 각 run 에 대해 validate-pr-metadata job 의 로그에서 ##[endgroup] 이후만 읽을 것.
# 그 앞은 스크립트 소스 에코이며 모든 에러 문구를 포함한다.

관련: #1927, #1929, #1925, #1883

[seonghobae]

데이터 경로 주장을 독립 확인했습니다. 그리고 수정 설계를 바꾸는 것 하나를 덧붙입니다 — base_sha 동등성 검사는 한 곳이 아니라 두 곳입니다.

확인: SUPPLIED_BASE_SHA는 정말 비교 전용입니다

origin/main의 opencode-review-dispatch.yml에서 전수 grep했습니다(잘라 읽지 않았습니다).

121:  SUPPLIED_BASE_SHA: ${{ github.event.client_payload.pr_base_sha || '' }}   ← 대입
186:  [ "$SUPPLIED_BASE_SHA" = "$live_base_sha" ] || mismatches+=("base_sha")   ← 비교
190:  printf '::error::... supplied_base=%s/%s ...'                             ← 에러 문구

세 곳이 전부입니다. 데이터로 쓰이는 곳이 없고, 하류(:295 :490 :526 :557)는 모두 needs.validate-pr-metadata.outputs.base_sha를 읽으며 그 값은 :199에서 live로 설정됩니다. "동등성은 데이터 의존이 아니라 staleness 정책"이라는 진단이 맞습니다.

그런데 두 번째 동등성 검사가 있습니다

opencode-review-target 잡(:2285 선언) 안, "Validate pull request head repository trust" 스텝(:2368)에 재검증이 있습니다.

2374:  EXPECTED_BASE_SHA: ${{ needs.validate-pr-metadata.outputs.base_sha }}
2390:  live_base_sha="$(jq -r '.base.sha // empty' <<<"$pull_request_json")"
2403:  [ "$live_base_sha" != "$EXPECTED_BASE_SHA" ] ||   → exit 1

이건 supplied 대 live가 아니라 검증 시점의 live 대 지금의 live입니다. 목적이 다릅니다(TOCTOU 재검증). 하지만 드리프트 문제는 똑같이 겪습니다. opencode-review-target은 validate-pr-metadata의 하류라 별도로 큐를 다시 통과합니다. 오늘 실측한 완주 실행에서 layer 간 대기가 2:19~4:57였으니, 두 검증 사이에 main이 또 전진할 확률이 매우 높습니다.

따라서 :186만 완화하면 실패가 사라지는 게 아니라 :2403으로 이동합니다.

왜 현재 데이터로는 이걸 볼 수 없는가

:2403의 실패율은 지금 측정 불가입니다. :186이 먼저 거의 전부를 걸러내기 때문에 :2403까지 도달하는 표본이 거의 없습니다. 44건 중 opencode-review에서 처음 실패한 것이 6건뿐인 것도 이것으로 설명됩니다 — 그 6건은 :186을 통과한 소수 생존자입니다.

이건 오늘 우리가 계속 걸린 그 형태입니다: **"이 표본에 무엇이 들어올 수 없었는가"**를 묻지 않으면 하류 실패율을 0에 가깝게 오독합니다. :186을 고치고 나서야 :2403의 진짜 실패율이 드러납니다.

제안: 두 곳에 같은 정책을, head는 양쪽 다 엄격 유지

허용 범위 안을 두 지점 모두에 적용하는 쪽을 권합니다. 판정은 GitHub compare API로 추가 체크아웃 없이 가능합니다(검증 잡은 이미 gh api repos/.../pulls/N을 호출하므로 토큰·도구가 이미 있습니다).

status="$(gh api "repos/${TARGET_REPOSITORY}/compare/${SUPPLIED_BASE_SHA}...${live_base_sha}" --jq '.status')"
case "$status" in
  identical|ahead) : ;;                      # base 가 같은 계보에서 전진만 함 -> 허용
  *) mismatches+=("base_sha") ;;             # behind/diverged -> 거부
esac

이러면 "base가 안 움직였다"는 보장을 **"base가 같은 계보에서 앞으로만 갔다"**로 바꿉니다. 무관한 커밋으로 갈아치우는 경우(diverged)는 여전히 거부되므로 보장을 통째로 버리는 게 아닙니다.

head_sha는 :188과 :2405 양쪽 다 엄격 유지해야 한다는 데 전적으로 동의합니다. exact-head 규율의 근간이고, 완화하면 디스패치된 커밋이 아닌 것을 리뷰하게 됩니다.

남는 설계 질문 (제가 정할 것 아님)

커버리지가 디스패치 당시와 다른 base에서 측정된다는 지적 그대로 남습니다. ahead 허용은 그걸 의도적으로 받아들이는 선택입니다. 다만 현재 상태는 그 선택을 안 한 게 아니라 파이프라인이 아예 완주하지 않는 것이므로, 비교 대상은 "정확한 base 커버리지"가 아니라 "커버리지 없음"입니다.

측정 방법 하나 칭찬드리면, ##[endgroup] 이후만 읽으신 것 — 그 앞 스크립트 소스 에코가 모든 에러 문구를 포함해서 어떤 가설이든 확증시킨다는 지적이 정확합니다. 저도 오늘 같은 함정을 다른 형태로 겪었습니다.

[seonghobae]

이 이슈가 불완전했습니다. base_sha 동등성 검사는 한 곳이 아니라 두 곳이고, :186만 완화하면 실패가 없어지는 게 아니라 :2403으로 옮겨갑니다.

독립 확인했습니다.

:121   SUPPLIED_BASE_SHA: ${{ github.event.client_payload.pr_base_sha || '' }}
:186   [ "$SUPPLIED_BASE_SHA" = "$live_base_sha" ] || mismatches+=("base_sha")     ← 1차 (validate-pr-metadata)
:190   에러 문구
        → SUPPLIED_BASE_SHA 는 데이터로 쓰이는 곳이 없음. 본문 주장 그대로.

:2374  EXPECTED_BASE_SHA: ${{ needs.validate-pr-metadata.outputs.base_sha }}       ← 검증 시점의 live 값
:2403  [ "$live_base_sha" != "$EXPECTED_BASE_SHA" ] || ...  → exit 1               ← 2차 (opencode-review-target)

두 검사는 목적이 다릅니다

:186은 staleness 정책입니다 — 디스패치가 실려온 값과 검증 시점 live의 비교. 본문에서 다룬 그것입니다.

:2403은 TOCTOU 재검증입니다 — 검증 시점 live와 리뷰 실행 시점 live의 비교. 목적이 정당합니다: OIDC·리뷰 토큰·CodeGraph·모델 호출 전에 메타데이터가 바뀌지 않았음을 재확인합니다. 같은 블록이 live_state != "open"과 head ref까지 함께 봅니다.

그런데 드리프트 노출은 동일합니다. opencode-review-target은 하류 job이라 큐를 다시 통과하고, 실측된 layer 간 대기가 2:19~4:57입니다. 그 사이 main이 또 움직입니다.

현재 데이터로는 2차의 실패율을 볼 수 없습니다

44건 전수에서 opencode-review가 첫 실패인 것은 6건뿐인데, 그 6건은 :186을 통과한 생존자입니다. 1차가 먼저 걸러내므로 2차까지 도달하는 표본이 거의 없습니다.

즉 "이 표본에 무엇이 들어올 수 없었는가"를 물어야 하는 경우이고, :186을 고쳐야 :2403의 진짜 실패율이 드러납니다. 본문의 분포는 1차 통과 이후를 과소 대표합니다.

수정 설계 정정

두 지점에 같은 정책을 적용해야 하고, head는 양쪽 모두 엄격 유지입니다.

검증 job이 이미 gh api repos/.../pulls/N을 호출하므로 토큰과 도구가 있어서 추가 체크아웃 없이 조상 관계를 물을 수 있습니다.

status="$(gh api "repos/${TARGET_REPOSITORY}/compare/${SUPPLIED_BASE_SHA}...${live_base_sha}" --jq '.status')"
case "$status" in identical|ahead) : ;; *) mismatches+=("base_sha") ;; esac

diverged는 여전히 거부되므로 보장을 통째로 버리는 게 아니라 **"안 움직였다" → "같은 계보에서 앞으로만 갔다"**로 약화하는 것입니다. 본문에서 대안으로 적은 "허용 범위"가 구체적으로 이 형태입니다.

:2403에도 같은 완화를 적용하지 않으면 1차 수정의 효과가 상쇄됩니다. 다만 :2403은 TOCTOU 방어라서 완화의 의미가 다릅니다 — 1차는 "오래된 디스패치를 받아들일 것인가", 2차는 "리뷰 도중 base가 전진한 것을 허용할 것인가"입니다. 후자가 커버리지 측정 기준점을 바꾸므로, 두 결정을 따로 내려야 합니다.

head_sha는 양쪽 다 엄격 유지가 맞습니다. exact-head 규율의 근간이고, 그건 대기 시간과 무관하게 지켜져야 합니다.

[seonghobae]

base_sha 드리프트 검사는 두 곳입니다 — 앞쪽만 풀면 실패가 이동할 뿐입니다

제가 다른 곳에서 ":190의 동등성은 데이터 의존이 아니라 staleness 정책이므로 풀어도 파이프라인은 동작한다"고 드렸는데, 불완전했습니다. 같은 드리프트를 검사하는 지점이 하나 더 있습니다.

:186   [ "$SUPPLIED_BASE_SHA" = "$live_base_sha" ] || mismatches+=("base_sha")
       디스패치 페이로드  vs  검증 시점의 live          → validate-pr-metadata

:2403  [ "$live_base_sha" != "$EXPECTED_BASE_SHA" ] || ...
       검증 시점의 live  vs  지금의 live                → opencode-review-target
       (:2374  EXPECTED_BASE_SHA = needs.validate-pr-metadata.outputs.base_sha)

두 검사가 같은 현상을 서로 다른 구간에서 잡습니다. 앞은 "디스패치 → 검증" 사이의 드리프트, 뒤는 "검증 → 하류 job 실행" 사이의 드리프트입니다.

뒤쪽 구간이 더 깁니다

하류 job은 자기 needs:가 끝나야 큐에 들어가므로 검증 직후가 아니라 큐를 한 번 더 통과한 뒤 실행됩니다. 관측된 완주 실행에서 admit-current-head 이후 홉들의 대기가 시간 단위였으니, :2403이 마주하는 드리프트 창은 :186의 것보다 작지 않습니다.

그래서 :2403의 낮은 실패 수는 건강의 증거가 아닙니다

:186이 대부분을 앞에서 거부하므로 :2403까지 도달하는 run 자체가 거의 없습니다. 그 관측치는 구조적으로 0에 가까울 수밖에 없고, 이를 "하류 검사는 문제없다"로 읽으면 안 됩니다. 정직한 진술은 **"상류 게이트가 서 있는 동안 하류의 실패율은 측정 불가"**입니다.

수정 권고 정정

:186만 완화하면 실패가 제거되는 게 아니라 :2403으로 이동하고, 이동 후에야 그 사실이 드러납니다. 그리고 그때는 이미 러너를 두 번 더 소비한 뒤입니다.

두 지점을 함께 다뤄야 합니다. 어느 쪽이든 결정은 동일한 축입니다 — base_sha 동등성을 (a) 유지할지, (b) 경고로 낮출지, (c) head_sha만 엄격히 두고 base는 live를 그대로 채택할지.

head_sha는 두 지점 모두에서 엄격히 유지해야 합니다. exact-head 규율의 근간이고, 드리프트해도 무해한 base와 달리 다른 커밋을 리뷰하게 되는 문제이기 때문입니다.

일반형

이건 이 이슈만의 이야기가 아닙니다. 파이프라인의 첫 실패 단계를 고칠 때는, 같은 근본 원인을 공유하면서 아직 도달된 적이 없어 실패 이력이 없는 후속 단계가 무엇인지 함께 물어야 합니다. 원인 귀속에는 "첫 실패 단계" 분류가 옳지만(캐스케이드 중복 계산 방지), 그 분류의 부수 효과로 후속 단계는 항상 건강해 보입니다.