release: GitHub Actions run 조회가 9시간 미래를 보던 문제 수정

[dldnsgkr]

develop → main. #164 하나뿐이고 마이그레이션 변경은 없다.

무엇을 고치나

GitHub Actions run 목록을 조회할 때 created=>= 필터를 atOffset(ZoneOffset.UTC) 로 만들고 있었다. afterTime 은 KST 벽시계로 저장된 LocalDateTime 인데 이 호출은 그 벽시계에 UTC 라벨만 붙인다. GitHub 은 진짜 UTC 로 필터링하므로 우리가 찾는 실행은 항상 9시간 밖으로 밀려나 결과가 언제나 0건이었다.

운영 실측으로 확인했다

triggeredAt 이 2026-08-18T14:37:40(KST) 인 배포로 GitHub API 를 직접 조회했다.

created>=2026-08-18T14:36:40Z   ← 보내던 값   →  0건
created>=2026-08-18T05:36:40Z   ← 맞는 값     →  3건, 첫 건이 completed success

대가 1 — 디스패치 직후 매칭이 늘 실패했다. pollWorkflowRun 이 5회 × 3초를 헛돌고 runId 없이 IN_PROGRESS 로 넘어간다. 지금까지 배포가 정상으로 보인 건 웹훅이 correlationId 로 매칭해준 덕이다.

대가 2 — 회수 워커가 성공한 배포를 닫았다. 어제 웹훅이 걸러져 멈춰 있던 운영 배포를 오늘 StuckDeploymentRecoveryWorker(#161) 가 집었는데, 같은 이유로 GitHub 실행을 못 찾아 "결과를 확인할 수 없습니다"로 FAILED 처리했다. 그 실행은 실제로 completed success 였고 사이트도 떠 있다.

해결

벽시계에 라벨을 붙이지 말고 그 타임존의 순간으로 해석한다(atZone(ZoneId.systemDefault())). 호스트가 KST 든 UTC 든 자기 DB 값과 어긋나지 않는다.

검증

• 마이그레이션 없음. 호출부 두 곳만 공통 헬퍼로 대체
• 테스트 4개 — 그중 하나는 오늘 실측한 사례를 고정한다(그 배포의 실제 실행 시각을 필터가 포함하는지). 잘못된 변환이면 깨진다
• ./gradlew test 전체 통과, CI 통과, dev 배포 성공(45ab272)

배포 후 할 일

운영 배포 이력 1번(projectId=11)은 실제로 성공했는데 FAILED 로 남아 있다. DB 를 직접 고치는 대신 재배포해 새 이력을 LIVE 로 남긴다. 그 재배포가 이 수정의 확인도 겸한다 — 디스패치 시점에 runId 가 잡히면 조회가 고쳐진 것이다.

관련: #161, #150, #162

🤖 Generated with Claude Code