CreateCaptureIntelligenceJob#run | error: Mysql2::Error::TimeoutError: Lock wait timeout exceeded; t

What Happened#

2026-08-05 04:56 KST, production cupixworks-worker (tesla)에서 editing publish 후속 처리 중 CreateCaptureIntelligenceJob#run이 Mysql2::Error::TimeoutError: Lock wait timeout exceeded로 1건 실패했다. Capture 748910의 editing 확정(editing_ready→editing_done) 이후 같은 captures row 748910 을 여러 worker/API 경로가 동시에 갱신하는 상황에서, job 의 queued_summary_state 상태 전이 UPDATE 가 InnoDB row lock 을 약 52초 대기하다 timeout 되었다. 에러는 rescue로 포착되어 job 은 false를 반환했고 프로세스 crash 는 없었으나, 해당 Capture 의 summary_state가 queued로 전이되지 못하는 기능적 누락이 남는다. 여기서 spacetime 1523661 은 lock 을 잡힌 row 가 아니라 Capture 가 속한 상위 그룹(captures.spacetime_id FK)이자 agent 로 전달되는 참조값이다 (아래 "spacetime 이 왜 엮이는가" 참조).

Quick Facts#

Affected Teams#

Timeline#

1. 2026-08-05 04:54:08 KST — editing_entity 1983936 (editing_id 1348459) 상태 ready→done, Capture 748910 editing_ready→editing_done (req b1c4986df503a12235690b83)
2. 2026-08-05 04:54:14–16 KST — after_done_editing_state 후속 처리: run_3d_reconstruction (job 1252197), CaptureInvoker#create_3d_reconstruction
3. 2026-08-05 04:54:18–20 KST — run_analysis 트리거, 별도 worker AnalyzePanoWorker#perform on 748910 (req 33bb84da...) 동시 시작
4. 2026-08-05 04:54:22 KST — CaptureInvoker#create_capture_intelligence job 1252198 생성, Capture#run_capture_intelligence 실행
5. 2026-08-05 04:55:02 KST — 또 다른 경로 Capture#update_associated_sitetracks (req 0e01edd1...) 및 #update_associated_deviations (req c2ce467b...) 가 같은 Capture 748910 갱신
6. 2026-08-05 04:55:18 KST — CreateCaptureIntelligenceJob#send_message SQS FIFO 전송 완료 (spacetime_id 1523661)
7. 2026-08-05 04:56:10 KST — CreateCaptureIntelligenceJob#run의 queued_summary_state UPDATE 가 lock 대기 ~52초 후 Lock wait timeout → rescue → job false 반환
8. 2026-08-05 04:56:11 / 04:57:03 KST — 같은 Capture 에 대한 API PUT /captures/748910/meta/prop [502] (동일 경합)
9. 2026-08-05 04:57:30–32 KST — 경합 해소, 이후 PUT /captures/748910 [200] 정상화

Scoring#

Confidence 85% · Actionability 36%

Confidence#

Actionability#