[devlasbe]

요약

관리용 history 엔드포인트의 "전체 조회 후 메모리 슬라이스"를 DB 레벨 LIMIT/OFFSET 페이지네이션으로 교체한다. OTA 경로는 미변경.

• PRD: 없음
• Figma: 없음

배경

• history 엔드포인트가 getPackageHistory(전체 릴리즈 조회)를 호출한 뒤 메모리에서 reverse().slice()로 잘라냈다.
• getPackageHistory는 조회한 모든 패키지에 presigned URL 서명 + diff 서브쿼리를 수행하고, 캐시는 isolate 메모리(5분)라 cold miss가 흔하다 → 릴리즈 677건 기준, 20개를 반환하려고 677건 전부를 서명·조회하는 구조.
• 사전 감사 결과 이 엔드포인트의 소비자(웹 HistoryPage / code-push-standalone CLI / 앱 배포 스크립트) 모두 blobUrl·diffPackageMap을 사용하지 않음. 상세: FE-68 스펙의 사이드 이펙트 감사.

변경 사항

• storage/d1.ts — 신규 getPackageHistoryPage(deploymentId, page, pageSize)
  • Before: (해당 없음 — 신규)
  • After: 페이지당 N개 row만 DB에서 조회
  • 세부:
    • LIMIT/OFFSET + ORDER BY uploadTime DESC, uploadTime 동률 대비 label 숫자 캐스팅(CAST(substr(label,2) AS INTEGER)) 보조 정렬 ("v10" < "v2" 문자열 비교 문제 회피)
    • COUNT 쿼리는 본 쿼리와 동일한 deletedAt IS NULL 필터 공유
    • presigned 서명·diff 조회 생략 → blobUrl/manifestBlobUrl은 "" (스키마가 required string, 소비자 전원 미사용 확인)
    • 무캐시 — 캐시 시 commitPackage/updatePackage 등 4곳 무효화에 전부 걸어야 해서 stale 리스크만 생김
    • 매퍼는 기존 mapPackageFromDB 재사용 → 필드 구성 기존과 동일
• routes/management.ts — history 핸들러 교체
  • Before: getPackageHistory(전체) → slice().reverse().slice()
  • After: getPackageHistoryPage 호출. 응답 shape({ history, totalCount, page, pageSize })·기본값(page=1/pageSize=20)·최신순 정렬 모두 불변
• storage/storage.ts
  • 인터페이스에 시그니처 1개 추가

변경하지 않은 것 (의도적)

• getPackageHistory 본체 — OTA(updateCheck)·rollback·release.update(label 검색)·release.create(중복검사/diff 생성)가 "전체·오름차순·diff·presigned·캐시" 계약을 공유하므로 그대로 둠. updateCheck의 전체 조회 비효율은 핫패스라 별도 티켓으로 분리.

테스트

• 기존 테스트 117/117 통과 (vitest)
• tsc / biome 통과 (warning 1건은 기존 metrics 핸들러 코드)
• 로컬 실데이터(릴리즈 677건) 검증: 파라미터 없음(CLI 방식) → totalCount 677, v677→v658 최신순 20개 / page=2&pageSize=5 → v672→v668 / 범위 밖 page=100 → 빈 배열 + totalCount 유지
• OTA 사이드 이펙트 확인: 실제 deploymentKey로 /updateCheck 호출 → v677 + downloadURL 정상
• 유닛 테스트 추가: 기존 스위트가 라우트·스토리지 레벨 커버, 신규 메서드 전용 테스트는 미작성

참고

• history 응답의 blobUrl/manifestBlobUrl이 presigned URL → 빈 문자열로 바뀜. 웹·CLI·앱 스크립트 모두 미사용 확인했으나, 혹시 이 필드를 쓰는 외부 소비자가 더 있다면 머지 전에 짚어야 함.
• 이 PR부터 base가 develop (main 직행 → develop 경유로 전환). main push 시 Workers Builds가 서버를 자동 배포하므로, develop 머지 시점에는 배포되지 않음.

🤖 Generated with Claude Code