44 lines
2.1 KiB
Markdown
44 lines
2.1 KiB
Markdown
# diff_review steps=[] 근본 원인 분석 + v0.3.13 수정
|
|
|
|
- **시간**: 2026-03-16 15:18~16:55
|
|
- **Commit**: `00b9491` → (후속 커밋 예정)
|
|
- **Vikunja**: #384 diff_review 원격 승인 테스트 → 🔧 진행중
|
|
|
|
## 분석 결과
|
|
|
|
2차 E2E 테스트에서 `AcknowledgeCascadeCodeEdit(steps=[])` → `SUCCESS: {}` 반환 확인.
|
|
RPC 자체는 성공하지만 빈 step 배열로 호출하면 no-op — AG의 diff review 바 유지됨.
|
|
|
|
**근본 원인 체인:**
|
|
1. Extension이 `writePendingApproval()`로 diff_review pending 생성 (edit_step_indices=[86] 포함)
|
|
2. Collector가 Gateway에 전달 후 로컬 pending 파일을 삭제 (collector.py L259)
|
|
3. Discord Accept 클릭 → Gateway → Collector가 response 파일 작성
|
|
4. Extension의 `processResponseFile`이 pending 파일에서 `edit_step_indices` 읽으려 함 → **파일 이미 없음**
|
|
5. `trackedSteps=[]` → `AcknowledgeCascadeCodeEdit(steps=[])` → no-op
|
|
|
|
## 수정 (v0.3.13)
|
|
|
|
- `diffReviewMetadata` 인메모리 Map 추가 (extension.ts L57)
|
|
- `writePendingApproval`에서 diff_review pending 생성 시 메타데이터를 메모리에 캐시
|
|
- `processResponseFile`에서 메모리 먼저 조회, pending 파일은 fallback
|
|
- `modifiedFiles` 변수를 Strategy 1/2 공유 스코프로 호이스팅
|
|
|
|
## 3차 E2E 테스트 (16:25~16:40)
|
|
|
|
- ✅ 인메모리 캐시 저장/로드 정상: `steps=[40]` → memory에서 로드
|
|
- ✅ RPC 호출 시 실제 step 인덱스 전달: `steps=[40]`, `steps=[101,114,123,126]`
|
|
- ❌ **RPC SUCCESS 반환하지만 AG diff review bar 미해제** — 실제 no-op
|
|
|
|
## 원인 분석 + 실험 (16:40~16:55)
|
|
|
|
RPC가 `SUCCESS: {}` 반환해도 unknown field를 무시하는 proto 동작일 가능성.
|
|
`stepIndices` 필드명이 AG 기대값과 다르거나, step index 값 자체가 불일치.
|
|
|
|
4가지 파라미터 형식 실험 코드 Extension에 배포:
|
|
- A: `stepIndices` (현재 방식)
|
|
- B: stepIndices 없이 (전체 accept)
|
|
- C: `steps` 키 (필드명 오류 가능성)
|
|
- D: `trajectoryId` 추가
|
|
|
|
→ AG 재시작 후 diff_review 트리거 시 각 형식의 결과 비교 예정
|