- Root cause: getDiagnostics.lastStepIndex is stale, SDK EventMonitor cannot detect real-time step changes
- Fix: Direct rawRPC('GetCascadeTrajectorySteps') polling every 5s
- Relay: PLANNER_RESPONSE, NOTIFY_USER, TASK_BOUNDARY, WAITING steps
- Added: docs/discord-bridge-analysis.md (full SDK architecture analysis)
- Added: docs/devlog/entries/20260308-003.md (trial-and-error history)
- Added: antigravity-sdk-main/ source reference
- Vikunja: #252 done, #253 created, #251 commented
2.2 KiB
2.2 KiB
Discord Bridge 딥 디버깅 — 시행착오 기록
- 시간: 2026-03-08 05:30~07:00
- Vikunja: #252 → done, #253 진행중, #251 코멘트 추가
시행착오 요약 (소거법)
❌ 시도 1: Bot 재시작 불필요
- 가설: Bot이 죽어서 메시지가 안 간다
- 현실: Bot은 PID 25508로 정상 동작 중이었음
- 배움: Bot 프로세스 확인은
Get-Process -Name python | Select PID,StartTime
❌ 시도 2: 수동 테스트 파일 깨짐 (BOM 인코딩)
- 가설: Bot이 파일을 안 읽는다
- 현실:
cmd /c echo {...} > file.json이 BOM(FF FE) 포함 UTF-16 생성 - 배움: 테스트 파일은 PowerShell Set-Content -Encoding UTF8 사용
- 증거: Bot 로그에
Expecting property name enclosed in double quotes반복
❌ 시도 3: getDiagnostics 기반 진단 폴링 무의미
- 가설: getDiagnostics 데이터로 step 변화를 잡을 수 있다
- 현실:
getDiagnostics.recentTrajectories.lastStepIndex가 실시간 업데이트 안 됨 - 증거: POLL#1~#2 모두
steps=1237 known=0고정 (실제 step은 1239+) - 배움: getDiagnostics는 세션 메타데이터용, 실시간 step 추적 불가
❌ 시도 4: SDK EventMonitor 의존 불가
- 가설: SDK monitor.onStepCountChanged가 실시간 감지
- 현실: EventMonitor._pollTrajectories()가 getDiagnostics 사용 → stale
- 배움: SDK EventMonitor는 실시간 step 추적에 부적합
✅ 최종 해결: rawRPC 직접 폴링
GetCascadeTrajectoryStepsrawRPC는 실시간 step 데이터를 정확히 반환- 5초 간격 폴링으로 PLANNER_RESPONSE, NOTIFY_USER, TASK_BOUNDARY, WAITING 릴레이
getDiagnostics는 active session ID 확인 용도로만 (최초 + 60초마다)
핵심 교훈
| # | 교훈 | 카테고리 |
|---|---|---|
| 1 | cmd /c echo로 JSON 만들지 마라 (BOM) |
Windows |
| 2 | getDiagnostics.lastStepIndex는 stale |
SDK |
| 3 | SDK EventMonitor는 getDiagnostics 의존 | SDK |
| 4 | rawRPC('GetCascadeTrajectorySteps')만 실시간 |
SDK |
| 5 | Step control은 vscode.commands 사용 |
SDK |
| 6 | 분석 문서는 brain이 아닌 프로젝트 docs에 저장 | 프로세스 |