From ebf2228aa8722ebeab0388f3e5509e6d1d2e3e78 Mon Sep 17 00:00:00 2001 From: Variet Worker Date: Wed, 18 Mar 2026 06:38:05 +0900 Subject: [PATCH] =?UTF-8?q?docs:=20known-issues=20=EC=A0=95=EB=A6=AC=20+?= =?UTF-8?q?=20Vikunja=20#410~#414=20=ED=83=9C=EC=8A=A4=ED=81=AC=20?= =?UTF-8?q?=EB=93=B1=EB=A1=9D=20=EB=B0=98=EC=98=81?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .agents/references/known-issues.md | 47 +++--------------------------- 1 file changed, 4 insertions(+), 43 deletions(-) diff --git a/.agents/references/known-issues.md b/.agents/references/known-issues.md index c834ff8..d557b61 100644 --- a/.agents/references/known-issues.md +++ b/.agents/references/known-issues.md @@ -40,57 +40,18 @@ ## 미해결 이슈 -### [2026-03-11] fs.watch silent fail — Discord→Extension 명령 전달 불가 -- **증상**: `!auto`, `!stop`, 텍스트 릴레이 등 Discord→Extension 방향 명령이 전부 작동 안 함. Extension log에 `[AUTO]` 로그 0건 -- **원인**: `watchCommandsDir()`의 `fs.watch`가 Windows에서 silent fail. watcher 세팅은 되지만 이벤트가 실제로 fire 안 됨 -- **해결**: `fs.watch` 유지 + 3초 `setInterval` 폴링 fallback 추가. `processAllCommands()` 함수로 공통화 -- **주의**: `fs.watch`는 Windows에서 구조적으로 불안정. **새 watcher 추가 시 반드시 polling fallback 병행** - ### [2026-03-11] rejectAgentStep — AG 미등록 VS Code 커맨드 - **증상**: `/stop` 및 거부 시 `antigravity.agent.rejectAgentStep` → `command not found` - **원인**: AG IDE가 이 커맨드를 런타임에 등록하지 않음 - **해결**: **미해결** — AG가 실제 등록하는 커맨드 목록 조사 후 올바른 커맨드로 교체 필요 - **주의**: AG 런타임 커맨드 미등록 문제의 근본 원인 (archive 참조: `[2026-03-09] VS Code Accept`) - -### [2026-03-16] pending 파일 무한 누적 — Collector/Bot이 로컬 파일 삭제 안 함 -- **증상**: `bridge/pending/` 디렉토리에 56개+ 파일 누적 (auto_resolved + pending) -- **원인**: `remote` 모드에서 Bot은 서버에서 동작하여 로컬 pending 파일 직접 삭제 불가 -- **해결**: **(미완료)** WS Hub 전환으로 파일 기반 IPC 자체가 줄어들면 자연 해소. Collector 정리 로직 일부 추가됨 -- **주의**: WS 연결 상태에서는 pending 파일을 아예 생성하지 않으므로 해당 없음 +- **Vikunja**: #411 --- -## 모니터링 중 이슈 (최근 수정, 재발 관찰 필요) - -### [2026-03-17] Hub pending_owners 생명주기 — WS 재연결 시 승인 응답 소실 -- **증상**: Discord에서 승인 클릭해도 AG Extension에서 아무 동작 안함 -- **원인**: `_disconnect()`에서 Extension 연결 끊기면 `pending_owners[rid]` 삭제 → 재연결 후 owner 정보 소실 -- **해결**: (1) 삭제 대신 같은 project 다른 연결로 재할당, (2) `_register_connection`에서 orphaned pending 재할당, (3) 같은 project 활성 연결 fallback -- **주의**: Gateway 모드에서 file bridge fallback은 **완전히 무용** — Docker 볼륨에 파일 작성하지만 Extension은 로컬 bridge/ 감시 - -### [2026-03-17] diff_review Accept All WS 경로 regression (v0.4.5 fix) -- **증상**: Discord에서 Accept all 클릭해도 AG에서 반응 없음 -- **원인**: WS 전환 시 `onResponse` 핸들러에 `diff_review` step_type 분기 누락 -- **해결**: `handleDiffReviewResponse()` export + WS `onResponse`에서 호출 -- **주의**: **WS 경로 추가 시 file-bridge 경로의 모든 분기를 반드시 포팅할 것** - -### [2026-03-17] _auto_approve_via_hub 이중 쓰기 (v0.4.5 fix) -- **증상**: auto-approve 시 Extension에 응답이 2번 도착 -- **원인**: Hub WS 전송 후 `return` 없이 file bridge에도 씀 -- **해결**: `if self.hub:` → WS 전송 + `else:` → file bridge. if/else 구조로 변경 -- **주의**: Hub WS와 file bridge는 **항상 상호 배타적**이어야 함 - -### [2026-03-17] WS dual-write — 채팅/승인 이중 발송 -- **증상**: Discord 메시지가 2개씩 도착 -- **원인**: `writeChatSnapshot`/`writePendingApproval`이 WS 전송 후 파일도 동시에 씀 -- **해결**: WS 연결 시 `return`으로 파일 쓰기 건너뛰기 -- **주의**: `writePendingApproval` 수정 시 diff_review metadata 캐싱 + memory dedup 로직이 WS 경로에서도 실행되어야 함 - -### [2026-03-17] ApprovalView Hub 응답 실패 시 silent loss — fallback 없음 -- **증상**: Extension이 pending 생성 후 WS 연결 끊김 → Discord 승인 클릭 → AG에 전달 안 됨 -- **원인**: `ApprovalView`가 Hub 전달 실패 시 file bridge를 건너뜀 -- **해결**: `send_response_to_pending_owner()` 반환값 확인 → `False`면 file bridge fallback (5곳) -- **주의**: `send_response_to_pending_owner`는 `pending_owners`에 conn_id가 없으면 `False` 반환. Hub 존재 ≠ 전달 성공 +> [!NOTE] +> v0.4.5 수정 사항(Hub pending_owners, diff_review WS, auto_approve 이중쓰기, WS dual-write, ApprovalView fallback)은 +> 코드 수정 완료됨. E2E 통합 검증은 Vikunja #410에서 추적 중. ---