[storage] Remove expired NotFatalUntil::M148 from quota CHECKs

IN REVIEW2026storage/browser/quotanot-fatal-until
2026. 9. 10.jmsmg 프로필 이미지jmsmg
https://crrev.com/c/8377550

//storage/browser/quota의 CHECK 153곳에 남아 있던 만료된 base::NotFatalUntil::M148 인자를 제거했습니다. 현재 트리는 M155라 M148은 이미 7개 마일스톤째 fatal이었고, base/not_fatal_until.h가 직접 지시하는 뒷정리입니다. 인자만 빼는 CL 1이고, 트리 잔여 4곳과 enum 항목 삭제는 후속 CL로 남겼습니다.

문제 설명

  • issue url: 없음 (코드에서 출발한 정리 작업, Bug: none)
  • 2026-02 CL 7601393이 //storage/browser/quota의 DCHECK를 CHECK(cond, base::NotFatalUntil::M148)로 바꿨습니다. M148 전까지는 덤프만 남기고 죽지 않게 해서, 더 엄격해진 검사를 단계적으로 켜기 위한 장치입니다.
  • 판정 로직(base/check.cc)은 지정 마일스톤이 현재 마일스톤 이하이면 그냥 LOGGING_FATAL입니다. chrome/VERSION의 MAJOR가 155이므로 이 153개 CHECK는 이미 fatal이고, 인자는 아무 효과 없이 남아 있었습니다.
  • 헤더(base/not_fatal_until.h)는 이미 fatal이 된 인자를 CHECK와 목록 양쪽에서 지우라고 명시합니다. 공식 빌드에서는 인자 없는 CHECK가 로그 문자열을 버려 코드가 더 작아집니다.

해결 내용

10파일의 CHECK 153곳에서 , base::NotFatalUntil::M148 인자만 제거했습니다(+154/−160). 조건식과 스트림 메시지는 그대로입니다.

-  CHECK(db_->HasActiveTransactions(), base::NotFatalUntil::M148);
+  CHECK(db_->HasActiveTransactions());

enum 항목은 이번에 지우지 않았습니다. 트리에는 M148 사용처가 4곳 더 있습니다(components/signin, media/audio/win 2곳, services/resource_coordinator). OWNER가 3그룹으로 갈리고 media/audio/win은 Linux에서 빌드가 안 되므로, 그 4곳과 M148 = 148, 삭제는 후속 CL로 분리했습니다. 이 사실은 diff만 봐서는 알 수 없어 커밋 메시지에 한 문장으로 남겼습니다.

동작 변화는 없습니다. 이미 fatal이었고 앞으로도 fatal입니다. 달라지는 것은 코드 생성뿐이며, 공식 빌드에서 CHECK 실패 시 크래시 리포트에 메시지가 실리지 않게 되는 트레이드오프는 원래 CL 설명에 적었습니다.

발굴 과정

만료된 NotFatalUntil 사용처를 마일스톤 단위로 전 트리에 대해 집계했습니다. M148은 157곳 중 153곳이 storage/browser/quota 한 디렉토리에 몰려 있어 OWNERS 한 그룹으로 끝나는 반면, 더 큰 M152(759곳)는 진행 중인 [dcheck-to-check] 프로젝트의 일부라 손대지 않았습니다. M148은 storage 팀의 일회성 롤아웃이고, 저희가 앞서 머지한 CL 8282239가 같은 근거로 QuotaDatabase 트랜잭션 CHECK에서 M148을 이미 제거한 선례가 있어 방향이 분명했습니다. 선점 확인으로 message:"NotFatalUntil" status:open 검색 9건 중 M148 정리 CL이 없는 것도 봤습니다.

테스트 방법

런타임 동작이 바뀌지 않는 정리라 새 테스트는 없고, 컴파일과 기존 테스트 통과가 검증입니다.

  • storage_unittests의 quota 관련 필터 313/313 통과 (Linux, 사전 실패 테스트 1개는 필터에서 제외).
  • 그 "사전 실패 테스트 1개"를 쫓다가 이 CL과 무관한 순서 의존 크래시를 찾아 별도 CL 8377022로 고쳤습니다. 처음엔 제 변경 탓으로 오판했는데, 대조군을 같은 필터로 돌리지 않은 것이 원인이었습니다.

리뷰

evanstade@가 하루 안에 Code-Review +1을 주면서 nit 하나를 남겼습니다. 커밋 메시지 본문(왜 이 변경이 타당한지 세 문단)이 전부 불필요하고 변경 자체로 자명하다는 것입니다. 본문을 두 문장으로 줄여 PS2로 올렸고, enum 항목을 남긴 이유 한 문장만 유지한 채 원하면 그것도 빼겠다고 답했습니다. 코드는 바뀌지 않아 재검증은 하지 않았습니다.

배운 점

  • 만료 정리처럼 자명한 변경은 커밋 메시지도 짧아야 합니다. 배경 설명이 길면 리뷰어에게는 읽을거리만 늘어납니다. 다만 diff로 알 수 없는 결정(왜 절반만 했는가)은 한 문장이라도 남기는 편이 뒤따를 질문을 줄입니다.
  • 마일스톤 단위로 집계하면 "한 디렉토리에 몰린" 정리 대상이 보입니다. CL을 OWNERS 경계로 나누면 승인 수집이 병목이 되지 않습니다.
  • 테스트가 깨졌을 때 대조군은 같은 필터로 돌립니다. 배치 크기가 다르면 순서 의존 실패는 보였다 안 보였다 합니다.

참고 자료

모든 컨트리뷰션 보기