[REFACTOR] 계층 산출물 쓰기에 잠금 소유권 검사를 넣는다 — 회수된 실행이 최신 산출물을 덮는다 #401

CodeRabbit PR #398 지적에서 출발. 그 PR 은 OVERVIEW 계층만 다루므로 여기서 계층 전체를 다룹니다.

문제

계층 콜백 안의 산출물 쓰기가 잠금 소유권을 확인하지 않습니다. attempt 를 받는 것은 markDone · markFailed 둘뿐입니다.

잠금이 회수된 뒤(#177 · 심장 5분 정지) 이전 실행이 늦게 응답하면, 그 실행이 최신 실행의 산출물을 덮습니다. 이후 markDone 이 옛 attempt 를 거절해도 데이터는 이미 바뀌어 있습니다.

전수 확인 결과 (AnalysisOrchestrator)

즉 "산출물 쓰기는 소유권을 안 보고, 상태 쓰기만 본다"가 지금의 설계입니다.

⚠ L3 가 가장 나쁩니다

replace 는 교체입니다 — 항목을 통째로 지우고 새 id 로 다시 만듭니다. 늦게 온 이전 실행이 이걸 실행하면 그 id 를 가리키던 것들이 전부 끊깁니다:

• review_log.target_id (특화 모델 학습 라벨)
• meeting_tuple_vector
• 사람이 열어 둔 검토 폼

지나간 회의의 라벨은 다시 만들 수 없습니다(V5.9 주석).

반면 OVERVIEW 가 잘못 덮이면 같은 회의의 조금 오래된 개요 문장이 남을 뿐이고, 폴백 값도 유효한 텍스트입니다. 그래서 우선순위는 L3 → 나머지입니다.

제안

attempt 를 산출물 저장까지 흘리고, 저장소가 같은 트랜잭션에서 analysis_layer 의 RUNNING·attempt 와 대조한 뒤에만 씁니다. 소유권이 바뀌었으면 건너뜁니다(예외 아님 — 회수는 정상 동작입니다).

포트 시그니처 7곳과 그 구현·테스트가 함께 바뀝니다.

창의 크기 (우선순위 판단 근거)

이전 실행의 Python 호출이 3분(read-timeout) 안에 안 끝나고 → 심장이 5분(LayerLiveness.STALE_AFTER) 넘게 멈춰 잠금이 회수되고 → 새 실행이 그 계층까지 도달해 끝낸 뒤에 옛 응답이 돌아와야 합니다.

좁지만 배포 중에는 실제로 일어나는 조합입니다 — #177 이 그래서 생겼습니다.

관련

• 출발: PR [FEAT] B-10 회의 개요 계층 — 없어도 되는 계층을 처음으로 나눈다 #398 (CodeRabbit 지적 ②)
• [FIX] 종료·크래시로 남은 RUNNING 계층을 되찾을 방법이 없다 — 그 회의는 영원히 분석되지 않는다 #177 (잠금 회수) · [FIX] 회수된 계층 잠금에 소유권 표시가 없다 — 뺏긴 실행이 새 실행의 상태를 닫을 수 있다 #212 (attempt 를 상태 쓰기에 실은 변경)