synchronize 최적화 disabled 이슈

阅读 handlers/webhooks.js 中的 handlePullRequestEvent，特别是 synchronize dispatch payload，然后检查 internal-dispatch.js 中的 handleTagPatterns 和 handlers/tag-patterns.js 中的 tagPatterns。跟踪 changedFilenames 应如何通过 worker path，并确认 synchronize 事件只分析已更改的文件，而不是完整集合。

배경

#7 에서 synchronize 이벤트가 오면 변경된 파일만 재분석하도록 tagPatterns()(handlers/tag-patterns.js)에 changedFilenames 파라미터를 추가했습니다. 값이 주어지면 해당 파일만 분석해 OpenAI 호출과 subrequest 사용량을 줄입니다.

문제

changedFilenames를 실제로 계산해서 넘기는 코드는 handlers/webhooks.js:336(getChangedFilenames 호출)뿐인데, 이 경로는 INTERNAL_SECRET/WORKER_URL이 없을 때만 타는 in-process 폴백입니다(윗 분기에서 env.INTERNAL_SECRET && env.WORKER_URL로 필터링 하는데 이는 항상 설정되어있는 것으로 추정됩니다(prod이므로)).

https://github.com/DaleStudy/github/blob/ae1c441a30407f62d1ac21a0bbb6d1d1aa6c19d6/handlers/webhooks.js#L328-L342

운영은 WORKER_URL이 항상 설정돼 있어 /internal/tag-patterns dispatch 경로(webhooks.js:300)만 탑니다. 이 경로의 페이로드에는 getChangedFilenames 호출이 없고, 이를 받는 internal-dispatch.js의 handleTagPatterns()도 tagPatterns()를 7개 인자로만 호출해 changedFilenames가 기본값 null(전체 분석)로 고정됩니다.

영향

• synchronize마다 변경 안 된 파일까지 전부 재분석 → OpenAI 토큰 낭비
• tag-patterns.js 상단 주석의 subrequest 한도(50) cliff(솔루션 파일 12~13개)에 다시 걸릴 위험 증가
• #7이 클로즈됐지만 운영에서는 사실상 미적용 상태

제안

• webhooks.js handlePullRequestEvent: synchronize 시 dispatch 페이로드 구성 전에 getChangedFilenames 호출 → payload에 포함
• internal-dispatch.js handleTagPatterns: payload에서 changedFilenames 꺼내 tagPatterns() 8번째 인자로 전달