chore: 호스트가 처리하지 못한 웹뷰 메시지를 관측한다 - #35
seongwon030 wants to merge 1 commit into
Conversation
같은 웹 화면이 홈 웹셸, ClubDetailScreen, webview/[slug] 세 WebView 안에서 도는데 메시지 처리 구현은 두 벌이다. 공용 훅과 홈의 인라인 switch가 서로를 모른 채 각자 자라서, 호스트마다 아는 메시지 목록이 다르다. 그 자체보다 나쁜 건 어긋남이 조용하다는 점이다. 공용 훅의 default는 console.warn만 남기고 홈의 switch는 default조차 없이 바깥 catch가 삼킨다. 그래서 웹이 6월(#1665)부터 보내던 SUBSCRIBE_TOGGLE을 상세 컨테이너가 버리고 있다는 사실을 12월에 사용자 제보로 알았다(ffb53d0). - 각 호스트 switch의 default에서 reportUnknownBridgeMessage를 부른다. dev는 console.warn, prod는 Mixpanel Bridge UnknownMessage 이벤트 - 판별 기준을 "알려진 타입 집합과 대조"가 아니라 "이 호스트의 switch가 잡지 못함"으로 뒀다. 홈만 처리하는 REQUEST_APP_VERSION처럼 호스트별로 목록이 다른 지금 구조에서, 집합 대조는 정상 처리된 메시지를 오탐한다 - 서드파티가 쏜 비정형 메시지를 거르려고 문자열 type만 취급한다. JSON 파싱 실패는 대상이 아니다. 기존 로그로 이미 드러나고, 비JSON을 쏘는 스크립트가 있으면 노이즈가 된다 - useWebViewMessageHandler의 host를 필수 옵션으로 뒀다. 웹뷰 호스트가 늘어날 때 타입 에러로 막혀 이름을 붙이게 된다 리포터는 void를 반환하고 예외를 밖으로 내보내지 않는다. 관측이 실패해도 메시지 처리는 계속돼야 한다. 기존 9종의 처리 경로는 건드리지 않았다. 갈라진 구현을 한 벌로 합치는 일은 이 PR의 범위가 아니다. 홈에만 있는 REQUEST_APP_VERSION, 호스트마다 다른 OPEN_EXTERNAL_URL 구현, NAVIGATE_BACK의 서로 다른 처리를 훅으로 흡수해야 해서 규모가 다르다. 그 전까지 이 관측 장치가 어긋남을 드러낸다. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (6)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughWebView 브리지 메시지 핸들러에 호스트 식별자를 추가했습니다. 알 수 없는 메시지는 호스트, 앱 버전, 플랫폼과 함께 진단 이벤트로 보고합니다. Changes브리지 메시지 진단 보고
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Feature Sequence Diagram(s)sequenceDiagram
participant WebView
participant MessageHandler
participant reportUnknownBridgeMessage
participant Mixpanel
WebView->>MessageHandler: 브리지 메시지 전달
MessageHandler->>reportUnknownBridgeMessage: 알 수 없는 type과 host 전달
reportUnknownBridgeMessage->>Mixpanel: BRIDGE_UNKNOWN_MESSAGE 이벤트 전송
Merge Risk: ⚪ Minimal · up to The change adds best-effort host-scoped diagnostics for unknown WebView messages without disrupting normal message handling, so no merge-blocking risk is established. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
왜
같은 웹 화면이 홈 웹셸,
ClubDetailScreen,webview/[slug]세 WebView에서 도는데 메시지 처리 구현은 두 벌(공용 훅 + 홈 인라인 switch)입니다. 호스트마다 아는 메시지가 다른데, 어긋나도 아무 신호가 없습니다. 공용 훅은console.warn만 남기고 홈은default도 없이 바깥catch가 삼킵니다.그래서 웹이 6월(Moadong/moadong#1665)부터 보내던
SUBSCRIBE_TOGGLE을 상세가 버리고 있다는 걸 12월에 제보로 알았습니다(#34).무엇을
각 호스트 switch의
default에서 리포터를 부릅니다. dev는console.warn, prod는 MixpanelBridge UnknownMessage.utils/webview.tsreportUnknownBridgeMessage추가constants/eventname.tsDIAGNOSTIC_EVENT그룹hooks/use-webview-message-handler.tshost필수화,default에서 리포트ui/home/home-webview-screen.tsxdefault추가ui/club-detail/club-detail-screen.tsx,app/webview/[slug].tsxhost전달+41 / -3
판별을 타입 집합 대조가 아니라
default로 한 이유 — 홈만 처리하는REQUEST_APP_VERSION이WebViewMessageTypes에 없어서, 집합 대조는 홈이 정상 처리한 메시지를 오탐합니다.문자열
type만 취급 — 서드파티 비정형 메시지 필터. JSON 파싱 실패는 대상 아닙니다(이미 로그로 드러남).안전성
리포터는
void를 반환하고 예외를 밖으로 내보내지 않습니다.default는 원래 아무것도 안 하던 자리라 기존 9종 처리 경로는 그대로입니다.검증
npx tsc --noEmitnpm run lint— 에러 0 (경고 5개는 기존styled임포트, 무관)window.ReactNativeWebView.postMessage(JSON.stringify({ type: 'TEST_UNKNOWN' }))범위 밖
구현을 한 벌로 합치는 건 별건입니다(
REQUEST_APP_VERSION, 호스트마다 다른OPEN_EXTERNAL_URL·NAVIGATE_BACK흡수 필요). 죽은 코드(NOTIFICATION_SUBSCRIBE/UNSUBSCRIBE— 웹 호출처 0개)도 그대로 뒀습니다.