큰 재귀 응답을 하위 트리로 나누어 복구

첫 2,000회 요청 실행은 1,995개를 확보했고, 캐시를 유지한 재개 실행 후 2,395/2,400개가 확보됐다. 남은 5개는 모두 Babel 버전이었다. 원래 일반 오류로 표시되던 실패를 분류하도록 보강한 뒤, 5개 모두 단일 응답의 로컬 8MiB 제한 초과임을 확인했다. 시간 초과나 인증 실패라고 추정하지 않았다.

별도 복구 계획을 먼저 고정했다. GitHub 공식 문서는 재귀 tree가 잘릴 때 비재귀 방식으로 하위 tree를 조회하도록 안내한다. 같은 구조를 이용해 큰 응답을 한 번에 허용하기보다 나누어 확보한다. GitHub Git trees 문서

--repair-subtrees는 확인된 응답 크기 초과 또는 명시적 truncated=true에만 반응한다. 부분 응답은 후보로 쓰지 않는다. 정확한 부모 tree의 항목에서 자식 ID를 얻고, 완전한 자식 재귀 응답을 재사용하거나 필요한 곳만 다시 비재귀로 나눈다. 일반 요청 실패·인증 실패·잘못된 객체·손상된 캐시는 이 경로로 숨기지 않는다.

네트워크 응답은 여전히 8MiB, 비재귀 항목 검증은 2MiB다. 원래의 전체 100,000항목·경로당 4,096바이트·경로 합계 16MiB 상한을 유지한다. 조립된 정규화 JSON 캐시의 해제 후 크기 상한만 32MiB로 분리했다. 수동 확장은 깊이 64와 root당 1,000개 비재귀 tree로 제한한다. 요청마다 30초, 최소 300ms 간격과 실행별 요청 예산을 적용한다.

자식 하나라도 실패하면 완성된 root 캐시를 저장하지 않는다. 이미 검증된 자식 캐시는 다음 실행에서 재사용할 수 있다. 조립 후에도 경로 중복·부모·객체 종류·ID·크기를 다시 검사하고 원자적으로 저장한다. 심볼릭 링크나 submodule 대상 파일은 열지 않는다.

go run ./cmd/riido-filecatalog --repair-subtrees --request-budget 1500 --out .cache/file-catalogs-repair-new

잘린 응답·크기 초과·일반 오류의 구분, 자식 실패 시 root 미저장, 완전한 조립, 캐시 재사용, 비정상 순환의 깊이 제한을 테스트했다. 전체 로컬 Go race/vet·형식·redacted 검사가 통과했다. 실제 복구와 최종 2,400개 오프라인 재현도 완료했다. 검색 품질이나 LLM 비용 결과는 아직 아니다.

후속 결과: 복구 실행이 정상 종료됐으며 763회 요청으로 최종 2,400/2,400개 확보를 확인했다. 최종 집계.