https://team-edo.github.io/tags/%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98/Recent content in 트랜잭션 on 얼쑤 · Team EdoHugoko-krWed, 28 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/compensate-failed-analysis-handoff/Wed, 28 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/compensate-failed-analysis-handoff/<p>얼쑤에서 같은 녹음의 분석을 다시 요청하면 세션을 <code>PENDING</code>으로 바꾸고 시도 번호를 올립니다. 실행기는 커밋 뒤에 작업을 받습니다. 상태가 반영되기 전 작업이 시작되면 새 시도를 읽을 수 없기 때문입니다.</p> <p>커밋과 작업 제출 사이에 실패할 수 있는 지점이 남습니다. 실행기의 대기열이 가득 차면 작업을 넘길 수 없지만, DB에는 이미 진행 중인 시도가 기록돼 있습니다. 이때 호출자에게 제출 실패만 돌려주면 상태를 읽는 쪽에는 아직 시작하지 못한 작업이 진행 중인 것처럼 보입니다.</p>https://team-edo.github.io/posts/2026/10/test-transaction-commit-boundary/Wed, 28 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/test-transaction-commit-boundary/<p>연주 분석에는 트랜잭션이 끝나는 시점이 중요한 일이 두 가지 있습니다. 분석 결과를 기록할 때는 세션 상태와 평가를 함께 저장합니다. 녹음이 올라왔을 때는 업로드가 확정된 뒤에만 분석을 시작합니다. 둘 다 오류를 던지는지만 확인하면, 앞서 실행한 쓰기나 바깥에 넘긴 작업이 남았는지 알 수 없습니다.</p> <h2 id="db에-실제로-남는-값을-읽었다">롤백 뒤 남은 DB 상태 확인</h2> <p>보통 매퍼 테스트는 테스트에 트랜잭션을 열어 두고 끝에서 한꺼번에 되돌립니다. 결과 저장의 원자성 검사에서는 테스트 트랜잭션을 열지 않았습니다. 테스트가 서비스 트랜잭션의 커밋 경계를 대신하면, 서비스를 벗어난 뒤에도 무엇이 남는지 구분하기 어렵기 때문입니다.</p>