fix(extension): diff_review RPC parameter experiment — 4 format variants (A/B/C/D) + known-issues update
This commit is contained in:
@@ -569,3 +569,8 @@
|
||||
- **해결**: `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 미해제 — 파라미터 형식 미스매치
|
||||
- **증상**: `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 무시 동작일 수 있음
|
||||
|
||||
Reference in New Issue
Block a user