[Fix] 원천 갱신 workflow 실패를 이슈로 드러내고 광주 보관 시간표 갱신에 수동 실행 경로 추가

[AquilaXk]

Related issue

Refs #860
Refs #870

Summary

• Problem:
  • 원천 갱신 workflow 4개가 2026-09-04~09-20에 2시간마다 실패했다. 실패를 알리는 경로가 없어 2주 넘게 아무도 몰랐고, 결국 수동 비활성화(disabled_manually)됐다.
  • 9/20 마지막 실패 원인(run 로그 기준)
    • current-capital-topology-refresh(run 35508995939): Prepare current ITX collection의 ITX current collection quota guard failed. 그날 첫 ITX 수집이 실패한 뒤 KST 하루 1회 한도 가드가 나머지 run을 모두 막았다. 일부 run은 capital topology transport NETWORK_TIMEOUT(run 35491747180)으로 실패했다.
    • kric-current-facility-refresh(run 35507969487): Recover claimed refresh의 no valid artifacts found to download. 남은 claim을 회수하려면 원래 run의 artifact가 필요한데, 보관 14일이 지나 영구히 회수할 수 없었다.
    • retained-gwangju-timetable-refresh(run 35508796441): retained timetable claim commit is invalid. 형태가 맞지 않는 claim 브랜치가 남아 매번 회수 단계에서 실패했다.
    • seoul-current-accessibility-refresh(run 35508666263): closed Seoul refresh claim requires manual resolution. 닫힌 갱신 PR의 claim 브랜치가 남아 fail-closed로 멈췄다.
  • 공통점은 자동 갱신 PR이 병합되지 않고 claim이 쌓인 것이다. 지금(2026-10-04) automation/* claim 브랜치는 원격에 0개다.
  • retained-gwangju-timetable-refresh에는 schedule만 있다. 그래서 [Fix] 수동 비활성화된 원천 자동 갱신 workflow 5개 복구 #860 완료 조건인 수동 dispatch 검증을 할 수 없다.
• Outcome:
  • 4개 workflow는 실패하면 workflow별 열린 이슈를 하나 만든다. 다시 실패하면 이슈 본문 상태 블록에 run을 쌓고, 댓글 알림은 하루 한 번만 단다(같은 run은 다시 쓰지 않는다).
  • 광주 보관 KRIC 시간표 갱신을 workflow_dispatch로 실행할 수 있다.

Changes

• tools/ci/report-refresh-failure.mjs(신규)
  • 대상은 원천 갱신 workflow 4개다. 그 밖의 workflow 이름이 들어오면 GitHub 호출 전에 거부한다.
  • 열린 이슈를 한 번 조회해, github-actions 봇이 만들고 제목이 정확히 [Fix] 원천 자동 갱신 실패: <원천> (<file>)이며 workflow 표지(<!-- easysubway-refresh-failure:<file> -->)가 있는 이슈만 센다(리뷰 F2).
    • 0개: 이슈를 만든다. 본문은 목표·배경(실패 run 링크)·완료 조건·실패 상태 블록과 Refs #860, Refs #870이다.
    • 1개: 이미 보고한 run이면 아무것도 쓰지 않는다. 마지막 알림 뒤 24시간 안이면 본문 상태 블록만 갱신하고, 지났으면 댓글 1개를 단 뒤 상태를 갱신한다(리뷰 F1).
    • 2개 이상: 가장 오래된 이슈에 그대로 기록한 뒤, 이슈 번호와 "하나만 남기고 나머지를 닫으면 정상 보고" 안내를 남기고 REFRESH_FAILURE_REPORT_DUPLICATE_ISSUES로 실패한다(리뷰 F2).
  • gh는 PATH 대신 고정 경로에서 찾고, 그 경로 해석과 실행기를 테스트로 덮는다(리뷰 F3).
  • 이슈 목록 응답이 배열이 아니면 중복 이슈를 만들지 않고 실패한다.
• 4개 갱신 workflow
  • 권한 블록을 갱신 job 레벨로 옮기고 issues: write를 추가했다. workflow 레벨은 permissions: {}다(리뷰 F4).
  • 마지막 단계로 if: ${{ failure() }} 보고 단계를 추가했다. continue-on-error는 쓰지 않는다.
• retained-gwangju-timetable-refresh.yml에 입력 없는 workflow_dispatch를 추가했다. 갱신 여부는 기존 decide(CURRENT면 외부 호출 전에 종료)가 그대로 판정한다.
• tools/ci/data-test-ownership.json에 새 테스트를 등록했다(owner data870).

Scope

Included

• 실패 이슈 보고, 광주 보관 시간표 dispatch 경로, 계약 테스트

Excluded

• workflow 재활성화(gh workflow enable): QA 승인 대상이라 메인 세션이 한다.
• ITX 수집을 topology 갱신에서 분리하는 구조 변경([Refactor] ITX-청춘 시간표 갱신을 데이터 레포 단독 경로로 분리 #857 범위)
• KRIC 편의시설 claim 회수가 14일 artifact 보관에 묶인 구조. 이번 PR의 실패 이슈로 14일 안에 드러나게만 한다.
• Slack 알림: data 저장소에 SLACK_RELEASE_WEBHOOK_URL secret이 없다(Data Pack Release run 37109648483 로그 SLACK_RELEASE_WEBHOOK_URL is not configured). secret 설정은 QA 승인 대상이다.

Ownership / dependencies

• Accountable owner or plan: Claude([Fix] 수동 비활성화된 원천 자동 갱신 workflow 5개 복구 #860, [Refactor] 데이터 파이프라인 운영 방식 전환: 자동 갱신·개발/발행 게이트 분리·생성 산출물 축소 #870)
• Required predecessor output: None
• Concurrent work overlap: tools/ci/data-test-ownership.json을 [Fix] 자정 이후 시발 열차 시각을 데이터팩 SQLite에 운행일 경계(03:00) 기준 24시 이후 초로 적재 #921·#924도 고친다. 서로 다른 줄에 한 줄을 넣었으므로 나중에 병합되는 쪽이 rebase한다.

Contract & Compatibility

• Source / API / schema contract: 변경 없음
• Artifact / provenance identity: 변경 없음
• Backward compatibility: 성공 run에는 보고 단계가 실행되지 않는다(failure()).
• Migration or cutover: 없음

Version impact

• no version change
• datapack release only
• route-map artifact change
• data contract change
• product gate JSON change
• CI workflow·계약 테스트 change

Product gate impact

• release/product-gates/** 영향 없음
• 변경한 gate의 근거를 갱신했습니다.
• 검증되지 않은 지원 범위 claim을 추가하거나 확대하지 않습니다.

Provenance impact

• source inventory·geometry provenance manifest 영향 없음
• 제공처·라이선스·갱신 시점·적용 범위를 갱신했습니다.
• 공식 source로 확인되지 않은 값을 배포 artifact에 추가하지 않습니다.

Version decision

• datapack version: 변경 없음
• data contract: 변경 없음
• route-map artifact / product gate: 변경 없음
• promotion request id: 해당 없음

Verification

Check	Result / Evidence
Focused RED → GREEN	계약 테스트를 먼저 썼다. 변경 전 workflow에서 current-capital-topology-refresh.yml needs issues: write와 retained workflow_dispatch 정규식 불일치로 2건 실패. 변경 후 node --test tools/ci/report-refresh-failure.test.mjs: 8/8 통과
Affected integration	node --test 갱신 workflow 계약·decide·delivery·ITX workflow 테스트 7개 파일: 53/53 통과. actionlint 4개 workflow: 오류 없음. data-test-discovery verify: 통과. anti-cheat guard: PASS
Required CI	Data contracts 결과는 PR check에서 확인
Live provider / release	Not required — reason: 외부 원천을 호출하지 않는다. 실제 gh issue list(읽기)로 열린 이슈를 조회해 계획만 출력하는 건식 실행을 했다(이슈 생성 없음).
Security / data integrity	새 권한은 issues: write 하나다. 본문에는 run URL만 넣고 경로·secret을 넣지 않는다(테스트로 고정).

Not run

• Check: 실제 실패 run에서의 이슈 생성
• Reason: workflow 4개가 disabled_manually이고, 재활성화·dispatch는 QA 승인 뒤 메인 세션이 한다.
• Rerun owner / condition: 메인 세션이 재활성화 뒤 첫 실패(또는 검증 dispatch) run에서 이슈가 만들어지는지 확인한다.

Risk

• Level: Medium
• Main risk: 실패가 이어지면 같은 이슈에 2시간마다 댓글이 쌓인다. 실패를 숨기지 않기 위해 의도한 동작이다.
• Failure behavior: 보고 단계가 실패해도 job은 이미 실패 상태다. 갱신 결과를 성공으로 바꾸지 않는다.
• Candidate / admission / publication state on failure: 변경 없음
• Fallback or degraded-success path introduced: No

Rollout / Recovery

• Rollout or promotion: 병합 뒤 QA 승인으로 workflow를 다시 켤 때부터 동작한다.
• Monitoring / success signal: 실패 run마다 [Fix] 원천 자동 갱신 실패: … 이슈 또는 댓글이 생긴다.
• Rollback or recovery: 이 커밋을 되돌린다.
• Existing artifact / schema compatibility after rollback: 영향 없음

Review focus

• 중복 이슈 판정(표지 기준)과 실패 시 동작
• 보고 단계가 각 workflow 마지막에 있고 failure()에서만 도는지

Checklist

• 이슈 범위와 실제 diff가 일치합니다.
• 관련 없는 변경이나 다른 owner의 surface를 포함하지 않았습니다.
• 위험에 필요한 검증과 미실행 사유를 기록했습니다.
• 실패·호환성·promotion·recovery 동작이 명확합니다.
• current failure를 이전·stale·alternate 결과의 성공으로 바꾸지 않습니다.
• GitHub PR Review 객체가 있는지 확인했습니다. CodeRabbit status check만으로는 리뷰 완료로 보지 않습니다.
• CodeRabbit Review 객체가 없으면 지원되는 Codex CLI 폴백 Review를 단일 GitHub PR Review로 게시했습니다.
• datapack 배포 영향이 있는 경우 release workflow 상태를 확인했습니다.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 0c26fe57-af19-42f8-bb37-5f86239a4ee7

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[AquilaXk]

Actionable comments posted: 4

🎯 Linked issue & acceptance criteria audit

• Linked issue: #860 Fix: restore five manually disabled source refresh workflows
• Goal summary: Restore refresh workflows; this PR adds failure alerts and a dispatch path.
• Acceptance criteria verified: 2/2

ID	Acceptance criterion	Status	Evidence
AC-ALERT	Repeated failures raise an alert instead of piling up silently	PASS	tools/ci/report-refresh-failure.mjs
AC-DISPATCH	Each workflow can be run once through workflow_dispatch	PASS	.github/workflows/retained-gwangju-timetable-refresh.yml

🛡️ Adversarial audit evidence

• Falsifiability verified: Yes (Probe on lines 44 and 46 of the reporter killed mutants by assertion failure.)
• Hollow assertions detected: 0
• Production backdoors detected: 0
• Ground-truth sources verified:
  • gh issue list JSON shape number and body
  • Issue 860 body acceptance criteria
  • ubuntu-latest gh install path /usr/bin/gh
• Mutation testing evidence: probe lines 44 and 46 killed; line 42 has no supported operator

🤖 Prompt for all review comments with AI agents

Could we verify each finding against the current code and keep only those that
still apply? Could we make the smallest validated fix and briefly note why any
finding no longer applies?

Inline comments:
- `@.github/workflows/seoul-current-accessibility-refresh.yml:8-11`
  Would moving the permissions block under the refresh job match the least-privilege
  intent for later edits?
- `@tools/ci/report-refresh-failure.mjs:39-44`
  Would restricting the match to issues created by the workflow token, or to a
  dedicated label, avoid false duplicates? Alternatively the duplicate error could
  name the issue numbers so the log points to the cleanup.
- `@tools/ci/report-refresh-failure.mjs:46-55`
  Could the comment path skip a run URL that the issue already mentions, and throttle
  to one comment per day, so a long outage stays readable? A test with the same run id
  twice would pin the behavior.
- `@tools/ci/report-refresh-failure.mjs:92-98`
  Could resolveGh accept an injectable existence check so a test can cover the found
  and missing cases, with `GH_EXECUTABLE` asserted for the missing case?

---

Outside diff comments:
None.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Aquila review of easysubway-data PR 926 using CLAUDE.md and the issue 860 body

Review profile: ASSERTIVE

Plan: Aquila fallback

Run ID: N/A (Aquila fallback)

Review source: Aquila CLI

Repository visibility: public GitHub repository

Trigger:
Manual discovery review requested by QA for the draft PR at current head

Base:
main@53f01fc5c4c5d2b7630c2c6dcdb79608200eaa1c

Head:
fix/refresh-failure-issue-860@7731176798f04c0889050eeea7e3648bd659ce7a

Command:
node aquila-review/scripts/post-review.mjs input.json payload-1.json --repo AquilaXk/easysubway-data --pr 926

📥 Commits

Reviewing files changed in this pull request between:

• Base: 53f01fc5c4c5d2b7630c2c6dcdb79608200eaa1c
• Head: 7731176798f04c0889050eeea7e3648bd659ce7a

📒 Files selected for processing (4)

• .github/workflows/retained-gwangju-timetable-refresh.yml
• .github/workflows/seoul-current-accessibility-refresh.yml
• tools/ci/report-refresh-failure.mjs
• tools/ci/report-refresh-failure.test.mjs

📜 Review details

[github-actions]

No description provided.

[github-actions]

No description provided.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud