fix(extension): acknowledgeCodeActionStep RPC discovery + v0.3.14 3-tier strategy

This commit is contained in:
Variet Worker
2026-03-16 18:10:56 +09:00
parent 82461bc3fc
commit 5a1d4f0b0c
7 changed files with 132 additions and 118 deletions

View File

@@ -569,8 +569,18 @@
- **해결**: `diffReviewMetadata` 인메모리 Map 추가 (extension.ts L57). `writePendingApproval`에서 diff_review pending 생성 시 `edit_step_indices` + `modified_files`를 메모리에 캐시. `processResponseFile`에서 메모리 먼저 조회, pending 파일은 fallback
- **주의**: 인메모리 캐시는 Extension Reload 시 소실됨. 그러나 diff_review pending 자체가 RUNNING→IDLE 전환 시 새로 생성되므로, 리로드 후에도 새 diff_review는 정상 동작. `bridge.py write_response()` L461의 pending 삭제도 동일 문제를 유발하지만 remote 모드에서는 Collector 경로만 해당
### [2026-03-16] AcknowledgeCascadeCodeEdit SUCCESS → diff review bar 미해제 — 파라미터 형식 미스매치
### [2026-03-16] AcknowledgeCascadeCodeEdit SUCCESS → diff review bar 미해제 — **잘못된 RPC 메서드명**
- **증상**: `AcknowledgeCascadeCodeEdit(session=xxx, accept=true, steps=[40])``SUCCESS: {}` 반환 → AG diff review bar 여전히 표시됨
- **원인**: RPC가 unknown field를 무시하고 빈 응답(`{}`) 반환하는 구조로 추정. `stepIndices`가 AG가 기대하는 필드명이 아니거나, step index 값이 AG 내부 인덱스와 다를 수 있음. 4가지 가설: (1) `stepIndices` 대신 `steps`, (2) stepIndices 없이 전체 accept, (3) `trajectoryId` 필요, (4) step index가 0-based vs offset 차이
- **해결**: (미완료) Extension에 4가지 파라미터 형식(A/B/C/D) 실험 코드 배포. AG 재시작 후 diff_review 트리거 시 각 형식의 결과를 extension.log에서 비교하여 올바른 형식 도출
- **주의**: RPC SUCCESS `{}`는 "파라미터가 맞지 않아 아무것도 안 함"과 "성공적으로 처리함"을 구분 불가. 에러가 아닌 빈 응답은 proto unknown field 무시 동작일 수 있음
- **원인**: **RPC 메서드명 자체가 틀렸음.** AG 내부 LS 메서드는 `AcknowledgeCascadeCodeEdit`가 아닌 **`acknowledgeCodeActionStep`**(proto ID 167). AG 소스 역분석으로 확인 — `jetskiAgent/main.js`에서 `acknowledgeCodeActionStep:async K=>{e&&await e.acknowledgeCodeActionStep(ur(vKa,K))}` 발견. Accept all 버튼 클릭 체인: `fireEvent({type:"accept-all-in-file"})``submitCodeAcknowledgement` 커맨드 → `acknowledgeCodeActionStep` LS RPC. `AcknowledgeCascadeCodeEdit`는 proto unknown field 무시로 `{}` 반환 (에러도 아닌 no-op)
- **해결**: v0.3.14에서 3단계 전략으로 변경: (1) `submitCodeAcknowledgement` VS Code 커맨드 (AG UI와 동일 경로), (2) `acknowledgeCodeActionStep` rawRPC, (3) `AcknowledgeCascadeCodeEdit` 레거시 폴백
- **주의**: AG의 RPC는 잘못된 메서드명도 에러 없이 `{}` 반환함. proto unknown field 동작으로 인해 디버깅이 매우 어려움. **반드시 AG 소스(`jetskiAgent/main.js`, `workbench.desktop.main.js`)에서 실제 메서드명을 확인** 후 사용할 것
### [2026-03-16] AG 소스 역분석 — diff review 내부 동작 체인
- **증상**: Accept all / Reject all 버튼의 내부 동작을 Extension에서 프로그래밍 방식으로 재현해야 함
- **원인**: AG 공식 API/문서 없음. VS Code 커맨드 중 많은 것이 미등록 상태
- **해결**: AG 설치 경로의 JS 소스에서 직접 역분석. 핵심 발견:
- **LS 메서드**: `acknowledgeCodeActionStep` (proto ID 167, 메시지 타입 `vKa`/`QLc`)
- **VS Code 커맨드**: `antigravity.prioritized.submitCodeAcknowledgement` (SUBMIT_CODE_ACKNOWLEDGEMENT)
- **Accept all 체인**: UI 클릭 → `fireEvent({type:"accept-all-in-file", uri: currentFile})``submitCodeAcknowledgement``acknowledgeCodeActionStep`
- **파일 위치**: `%LOCALAPPDATA%\Programs\Antigravity\resources\app\out\jetskiAgent\main.js` (LS 메서드 정의), `vs\workbench\workbench.desktop.main.js` (UI 커맨드 + 핸들러)
- **주의**: Python `re.finditer`로 대용량 JS 검색 시 PowerShell `IndexOf`보다 안정적. minified JS에서 변수명(`vKa`, `QLc` 등)은 버전마다 변경됨