[MCP] Antigravity 재개 세션의 roots 알림을 400 으로 거절해 Kandev 도구가 끊긴다 #32

New Issue

2026-10-04T23:35:16+09:00

dreampiler commented

2026-10-04 23:35:16 +09:00

증상: Gemini 3.8 Flash(antigravity-acp 1.2.1) 세션이 「The MCP server 'kandev' failed to initialize: sending "notifications/roots/list_changed": Bad Request」로 멈춘다(09-25~10-04 23건). 실측(운영 세션 10-04): 23건 모두 같은 세션에서 앞서 Kandev 도구를 쓰다가 Antigravity 가 쉬던 대화를 다시 불러온 직후(백엔드 로그 「restoring existing ACP session」, native_session_resume=true)에 났다 — 첫 턴 실패 0. 재현: agentctl MCP 엔드포인트(/mcp)에 {"jsonrpc":"2.0","method":"notifications/roots/list_changed"} 를 Mcp-Protocol-Version: 2026-07-28 헤더로 보내면 400 「missing or invalid _meta field io.modelcontextprotocol/protocolVersion」(mark3labs/mcp-go v1.0.0-beta.1 server/streamable_http_modern.go validateModernRequest — 새 규격 요청은 헤더와 본문 _meta 둘 다 버전을 요구), 헤더 없음·2025-06-18 이면 404 Invalid session ID(400 아님). 즉 재개된 Antigravity 클라이언트가 새 규격 헤더로 알림을 보내면서 본문 _meta 를 안 싣고, mcp-go 가 알림에도 _meta 를 요구해 거절한다(어느 쪽 규격 해석이 맞는지는 확인 필요 — 추정). 고칠 것: Kandev MCP HTTP 처리에서 본문 _meta 가 없는 알림(id 없는 메시지)은 헤더 버전을 _meta 로 채워 넘기거나 202 로 받는다(Kandev 서버는 roots 를 쓰지 않는다) — 요청(id 있음)은 지금 검증 유지. 가능하면 mcp-go 쪽 알림 처리도 확인(업스트림 이슈는 소유자 결정). 확인: 같은 재현 요청이 202, Antigravity 세션을 쉬게 했다가 재개해 Kandev 도구 호출이 되는지. 운영 우회(같은 날): 감시가 같은 프로필 MCP 초기화 24시간 2회 넘게 실패면 다른 모델로 넘긴다. Kandev R3(다음 회차, R2 배포 뒤).

증상: Gemini 3.8 Flash(antigravity-acp 1.2.1) 세션이 「The MCP server 'kandev' failed to initialize: sending "notifications/roots/list_changed": Bad Request」로 멈춘다(09-25~10-04 23건). 실측(운영 세션 10-04): 23건 모두 같은 세션에서 앞서 Kandev 도구를 쓰다가 Antigravity 가 쉬던 대화를 다시 불러온 직후(백엔드 로그 「restoring existing ACP session」, native_session_resume=true)에 났다 — 첫 턴 실패 0. 재현: agentctl MCP 엔드포인트(/mcp)에 `{"jsonrpc":"2.0","method":"notifications/roots/list_changed"}` 를 `Mcp-Protocol-Version: 2026-07-28` 헤더로 보내면 400 「missing or invalid _meta field io.modelcontextprotocol/protocolVersion」(mark3labs/mcp-go v1.0.0-beta.1 server/streamable_http_modern.go validateModernRequest — 새 규격 요청은 헤더와 본문 _meta 둘 다 버전을 요구), 헤더 없음·2025-06-18 이면 404 Invalid session ID(400 아님). 즉 재개된 Antigravity 클라이언트가 새 규격 헤더로 알림을 보내면서 본문 _meta 를 안 싣고, mcp-go 가 알림에도 _meta 를 요구해 거절한다(어느 쪽 규격 해석이 맞는지는 확인 필요 — 추정). 고칠 것: Kandev MCP HTTP 처리에서 본문 _meta 가 없는 알림(id 없는 메시지)은 헤더 버전을 _meta 로 채워 넘기거나 202 로 받는다(Kandev 서버는 roots 를 쓰지 않는다) — 요청(id 있음)은 지금 검증 유지. 가능하면 mcp-go 쪽 알림 처리도 확인(업스트림 이슈는 소유자 결정). 확인: 같은 재현 요청이 202, Antigravity 세션을 쉬게 했다가 재개해 Kandev 도구 호출이 되는지. 운영 우회(같은 날): 감시가 같은 프로필 MCP 초기화 24시간 2회 넘게 실패면 다른 모델로 넘긴다. Kandev R3(다음 회차, R2 배포 뒤).

dreampiler commented

2026-10-04 23:48:22 +09:00

10-04 소유자 「W-032는 긴급으로 바로 처리해줘.」 — R3 가 아니라 긴급 배포로 상시 관제(8e3eb6b7) 직속 Kandev 작업 1c15714e 로 등록·시작(고난도, 6 Sol). 병합 뒤 운영 세션이 긴급 배포.

dreampiler commented

2026-10-07 16:28:00 +09:00

[KANDEV-W-032 반영·정리] 한 일: 중복 해소 대조 완료. 해결 PR #76(fix(mcp): accept header-only modern notifications, 90dc4a0e65)이 10-05 병합되어 origin/main(c4c26e8345)에 포함됨을 merge-base로 확인. 작업 브랜치 feature/kandev-w-032-mcp-roo-0gn는 origin/main과 diff 없음(clean, 코드 변경 0건). 검토 판정 통과. 근거: 구현 notification_protocol_compatibility.go + server.go 양쪽 /mcp 등록 배선 확인, TestMCPProtocolCompatibility 통과, id 있는 요청 400 유지로 요청 검증 유지. 남은 것: Task 02 실제 재개 검증(동일 native conversation 복원 후 동일 read-tool 재호출 확인)은 미완으로 검증230 원목록에 유지. 합성 202를 전체 PASS로 주장하지 않음. 후속 제안: 관제에서 Task 02 실재개 검증 절차를 검증230 소유자에게 인계. 병합할 PR 없음(이미 #76으로 병합됨).

dreampiler closed this issue

2026-10-07 16:43:37 +09:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dreampiler/kandev#32