기여 목록 / 8429006
CacheStorage: Diagnose responses rejected by add() and addAll()
Cache.add()와 Cache.addAll()이 성공 상태가 아닌 응답을 거부할 때, 실패한 요청 URL과 응답 유형에 따른 원인을 콘솔에 표시하도록 개선했습니다. JavaScript에 전달되는 기존 예외와 캐시 처리 동작은 유지합니다.
문제 설명
기존 구현은 성공 상태가 아닌 응답을 받으면 TypeError: Request failed만 반환했습니다. 개발자는 어떤 요청이 실패했는지, 응답을 캐시에 넣을 수 없는 이유가 무엇인지 알기 어려웠습니다. 특히 여러 요청을 한 번에 처리하는 addAll()에서는 실패한 요청을 구분하기가 더 어려웠습니다.
opaque 응답은 실제 서버 응답이 성공했더라도 필터링된 상태 코드가 0이므로 add()와 addAll()의 성공 응답 조건을 만족하지 못합니다. 하지만 기존 오류만으로는 이 제약이나 Cache.put()을 사용할 수 있다는 대안을 파악하기 어려웠습니다.
해결 내용
응답 유형별 실패 원인 생성
third_party/blink/renderer/modules/cache_storage/cache.cc에NonOkResponseReason()을 추가했습니다. 모든 현재FetchResponseType값을switch로 명시적으로 처리합니다.응답 유형 콘솔 진단 내용 kBasic,kCors,kDefault필터링된 응답 상태 코드가 성공 범위인 200–299에 해당하지 않음을 설명합니다. kOpaque상태 코드가 공개되지 않아 추가할 수 없음을 설명하고 Cache.put()사용을 안내합니다.kOpaqueRedirectopaque redirect의 상태 코드가 공개되지 않음을 설명하고 Cache.put()사용을 안내합니다.kError네트워크 오류를 설명합니다. 실제 fetch는 보통 이 처리기에 도달하기 전에 거부되지만, 해당 응답 유형도 명시적으로 처리합니다. 실패 요청을 식별하는 콘솔 메시지 추가
OnNonOkResponse()에서 메서드 이름, 원래 요청 URL, 실패 원인을 오류 수준의 콘솔 메시지로 기록합니다. 요청 URL은request_list_[index]에서 가져오며, 응답의 내부 리다이렉트 URL이나 필터링 전 상태 코드를 사용하지 않습니다.JavaScript에 전달되는 예외는 기존의
TypeError: Request failed를 유지하여 응답 세부 정보가 예외에 추가되지 않도록 했습니다.중복 진단만 억제하고 기존 오류 처리 유지
응답 수집이 중단되지 않았고 실행 컨텍스트가 유효할 때만 콘솔 메시지를 출력합니다. 이 조건으로
addAll()에서 첫 실패 이후에 도착하는 응답의 중복 진단을 억제합니다.리뷰에서는 초기 구현의 조기 반환이 기존
OnError()호출까지 건너뛴다는 점이 지적되었습니다. Patch Set 2에서는 조건을 콘솔 출력에만 적용하고OnError("Request failed")는 항상 호출하도록 수정했습니다. 배치 취소와 일부 응답만 저장되지 않도록 하는 기존 동작을 유지합니다.
테스트 방법
third_party/blink/renderer/modules/cache_storage/cache_test.cc에 CacheStorageAddTest를 추가하여 add()와 addAll()을 매개변수화된 테스트로 검증합니다. 여러 요청에 서로 다른 응답을 반환할 수 있도록 테스트용 fetcher도 확장했습니다.
| 테스트 | 검증 내용 |
|---|---|
NonOkResponseLogsStatusAndRequestUrl |
default/basic/CORS 응답의 404·500 상태에서 원래 요청 URL과 상태를 출력하고 기존 예외를 유지하는지 확인합니다. |
OpaqueResponseLogsReasonWithoutExposingDetails |
opaque 응답의 내부 URL이나 원래 상태를 노출하지 않고 실패 이유와 대안을 안내하는지 확인합니다. |
OpaqueRedirectResponseLogsReasonWithoutExposingDetails |
opaque redirect에도 필터링된 정보만 사용해 진단하는지 확인합니다. |
ErrorResponseLogsNetworkError |
모의 fetcher가 반환한 error 응답에 네트워크 오류 진단을 출력하는지 확인합니다. |
SuccessfulStatusDoesNotLogAnError |
200·201·204 응답이 응답 검증을 통과해 캐시 백엔드에 도달하고 오류 로그를 남기지 않는지 확인합니다. |
AddAllLogsOnlyTheFirstFailingRequest |
200·404·500 응답을 순서대로 반환하여 첫 실패인 404 요청만 진단하고, 배치가 취소되며 백엔드 작업이 호출되지 않는지 확인합니다. |
기존 배치 취소 테스트에도 콘솔 메시지가 하나만 남는다는 검증을 추가했습니다. 커밋 메시지에는 관련 CacheStorage C++ 테스트 21개를 통과했다고 기록되어 있습니다.
리뷰에서는 WPT 추가 필요성도 논의했습니다. 작성자는 기존 WPT가 응답 거부와 배치 원자성을 다루고 있으며, 이번 변경은 표준화되지 않은 Chromium 콘솔 진단이므로 새 문구와 첫 실패 식별을 C++ 테스트로 검증한다고 설명했습니다.
Gerrit 기록상 Patch Set 2는 2026년 9월 23일 UTC에 CQ dry run을 통과했습니다. 9월 24일에는 코드 리뷰 승인 두 건과 Commit-Queue +2가 기록되고 full run이 시작되었습니다. 보고서 작성 시점에는 최종 병합 완료 결과가 확인되지 않았습니다. 위 테스트 결과는 커밋과 Gerrit 기록을 기준으로 정리했으며, 보고서 작성 과정에서 Chromium 테스트를 별도로 실행하지는 않았습니다.
배운 점
- 개발자용 콘솔 진단을 개선하면서도 JavaScript에 노출되는 예외 타입과 메시지는 유지할 수 있습니다.
- 요청 URL과 응답 URL, 필터링된 상태와 내부 상태를 구분해야 opaque 응답의 비공개 정보를 노출하지 않고 진단할 수 있습니다.
- 중복 로그를 억제하는 조건이 오류 처리와 취소 흐름까지 건너뛰지 않는지 확인해야 합니다.
- 비동기 배치 테스트에서는 실패 여부뿐 아니라 어느 요청의 실패를 보고하는지와 후속 응답의 중복 로그까지 검증해야 합니다.