자동전환 미반영 — 게스트 socket.io 업링크 26초 stall 원인 분석 및 로깅 추가 분석로깅

결론 — 범인부터 공개한다

수사 일지 ① — 사건 발생 VOC

수사 일지 ② — 초동 수사: 세 증인의 시계를 맞추다

06:04:54.317  [게스트] auto-finish 발동 → goToNextStep (하랑대화1→2 자체 전환)
06:04:54.322  [게스트] socket.emit(guest-step-update act1) · notifyAutoFinish 호출 ✅
              └ 클라는 emit 호출했으나… 서버 미도달
06:04:56.7    [게스트] 호스트 "응" 메시지 수신 정상(다운링크 OK)
06:05:00.909  [서버]  Host changed step act1 ← 진행자 수동 점프(host→server 실시간 정상)
06:05:06.507  [서버]  monitoring peer …c7c32921 disconnect ← 진행자 모니터 새로고침
06:05:07.046  [서버]  Host requested room state {hasState:true} → stale(act0/1) 복원
06:05:17/18   [서버]  Host changed step act0/1 ← 진행자 "새로고침" 버튼(stale push) → 아동 회귀
06:05:20.580  [서버]  Guest auto-finish {matchedCondition} ← 26초 만에 첫 도달
06:05:20.623  [서버]  Guest step update act1 ← 26초 만에 첫 도달

수사 일지 ③ — 용의자 배제: 서버 로그로 확정

• 게스트→서버 26초 지연: 클라 emit(06:04:54.322) ↔ 서버 수신(06:05:20.623). 같은 쿼리 윈도우(전 인스턴스, 절단 없음)에서 그 사이 act1 수신 0건.
• 클록 오차 배제: 호스트 수동 점프 한 이벤트를 3곳(호스트 클라 06:05:00.816 → 서버 .909 → 게스트 클라 .971)이 기록 → 세 클록이 ~150ms 안에 정렬. 26초는 클록 차이가 아님.
• 서버/인스턴스 정상: 같은 시각 다른 룸 a77c4cf8_5의 guest-step-update는 정상 연속(최대 공백 5.4초). 우리 룸만 27.4초 공백.
• 게스트 소켓 disconnect 없음(서버 확인) + 게스트 mediasoup transport RTT 보고도 04:52→05:20 동일 28초 공백. = 게스트發 모든 데이터가 그 구간 안 올라감.
• 수신은 정상: 같은 구간 server→guest("응", 스텝변경)는 60ms 내 도달. = 다운링크 정상, 업링크만 stall.

수사 일지 ④ — 결정적 단서: Grafana ppi-socket 조회로 stall 확인

대시보드 실시간 로그 패널(ppi-logs)은 행 가상화로 스크롤이 안 돼, Loki query_range API를 직접 호출해 roomId로 필터링했다.

# LogQL — 룸 단위 전 인스턴스, 시각 윈도우
{service="ppi-socket", env=~"prod"} |= "id-011-586a-4d1f-a415-747776dec5c7_42"

# 패널이 가상화돼 스크롤 불가 → Grafana 프록시로 직접 호출
GET /api/datasources/proxy/uid/<lokiUid>/loki/api/v1/query_range
    ?query=...&start=<ns>&end=<ns>&direction=forward&limit=5000

① 게스트→서버 step-update 수신 (26초 공백)

06:04:53.272  Guest step update in room …_42 {"activityIndex":0,"stepIndex":1}   ← 마지막
              ⟨ 06:04:54 게스트가 act1 emit… 서버 수신 0건 ⟩
06:05:20.580  Guest auto-finish from guest-…_42 {"matchedCondition":"그러면같이한번찾으러가보자!"}  ← 26s 만에
06:05:20.623  Guest step update in room …_42 {"activityIndex":1,"stepIndex":0}   ← 26s 만에

② 호스트 모니터 새로고침(리마운트) + stale 복원

06:05:00.909  Host changed step …_42 {act1}                       ← 진행자 수동 점프(정상 실시간)
06:05:06.507  Cleaning up peer monitoring:…c7c32921… after disconnect ← 모니터 소켓 끊김
06:05:07.040  Peer …c7c32921…-545e7890 joined room, found 3 existing producers ← 재입장
06:05:07.046  Host requested room state …_42 {"hasState":true}    ← stale(act0/1) 복원

③ 게스트 mediasoup transport RTT — 동일 28초 공백

# {…} |= "Guest transport state: guest-id-011…_42"
04:52.307  RTT=9ms      ← 정상(초당 보고)
   ⟨ 04:52 → 05:20  보고 0건 (step-update 공백과 동일 구간) ⟩
05:20.580  RTT=9ms / 05:20.715  RTT=102ms  ← 복구 찰나 스파이크

RTT 값이 아니라 보고 자체가 28초 끊김 = 게스트發 모든 데이터(step-update·auto-finish·transport stat)가 그 구간 안 올라감.

④ 다른 룸과 비교 — 같은 시각 정상 (서버/인스턴스 무죄)

# {…} |= "Guest step update in room" — 06:04:50~06:05:22, 룸별 최대 공백
a77c4cf8…_5    6건   maxGap 5.4s   ← 정상 연속
id-011…_42   7건   maxGap 27.4s  ← 우리 룸만 이상

수사 일지 ⑤ — 범행이 은폐된 이유 1: 왜 disconnect가 안 떴나 (= 복구도 안 걸림)

engine.io 하트비트는 서버 PING(다운링크) → 클라 PONG(업링크). PONG도 같은 WebSocket/TCP 스트림이라 stall 동안 같이 묶인다. 그런데:

disconnect 이벤트가 없으니 socket.io 재연결·앱의 connect 기반 복구가 하나도 안 걸렸고, 보낸 emit은 그냥 26초 대기. (※ 25/20s는 기본값 — 단, "disconnect 미발생" 경험 사실만으로 "한계 미초과"는 확정)

수사 일지 ⑥ — 범행이 은폐된 이유 2: 왜 모니터 네트워크 경보도 안 떴나 (탐지 사각지대)

useMonitorNetworkLevel은 4개 입력을 보는데, 이 stall은 전부 미충족:

수사 일지 ⑦ — 2차 피해: "새로고침" 버튼의 stale push

진행자 모니터의 guestCurrentStep은 게스트發 이벤트로만 갱신된다(use-host-socket.ts). 호스트 자신의 수동 점프는 갱신하지 않음. 26초간 게스트 업데이트 미수신 + 06:05:06 리마운트의 stale 복원으로 그 값은 하랑대화1에 멈춤.

수사 일지 ⑧ — 용의자 신상: 안드로이드 태블릿 추정 + 모바일 업링크

• 게스트 LogRocket: platform: "Linux armv81"(ARM) + 전면 카메라 + 데스크톱 UA(X11; Linux x86_64) → 안드로이드 태블릿(데스크톱 사이트 모드) 추정.
• 이번 stall은 포그라운드 active(수업 중)라 Doze/App Standby는 무관. 포그라운드 업링크 stall은 셀룰러 RRC promotion/tail, Wi-Fi 절전·로밍, 전환 시 WebRTC 재협상 경합이 후보 — 양 OS 공통이나 모바일 특성.

수사 일지 ⑨ — 감시망 구축: 업링크 stall 감지 로깅 추가 (LogRocket)

연결은 유지(disconnect 미발생)되나 emit이 서버에 안 닿는 stall을 클라가 ack+타임아웃으로 감지해 LogRocket 커스텀 이벤트로 기록. 사후 분석 시 "자동전환 미반영 = 업링크 stall"을 즉시 식별.

// apps/web/lib/socket-uplink-stall-detector.ts (신규)
export function emitWithUplinkStallDetection(eventName, payload, { timeoutMs = 5000, roomId }) {
  if (!socket.connected) { socket.emit(eventName, payload); return; } // 미연결은 버퍼링·판정 제외
  socket.timeout(timeoutMs).emit(eventName, payload, (err) => {
    if (err) trackEvent("GuestUplinkStall", {...});        // ack 미수신 = 업링크 정체 (시작 1회)
    else if (wasStalled) trackEvent("GuestUplinkRecovered", { stalledMs }); // 복구 1회
  });
}

남은 수사 — 범위 & 후속

이번 작업은 감지·로깅만 — stall을 고치거나 재전송하지 않음. 백로그:

• 2크리티컬 emit ack 실패 시 재전송 — 누락 근본 차단.
• 7모니터 "동기화 지연" 표시 — 게스트發 무신호 N초 시 진행자에 노출 → 수동개입(새로고침 stale push) 2차 피해 방지.
• 10"새로고침" 버튼 가드 — stale guestCurrentStep push 금지(미확인 시 비활성/게스트 재요청).
• engine.io transport(bufferedAmount/ping RTT) 샘플링 · 네트워크 메타(navigator.connection) 캡처 · 게스트 하트비트.