KamoCRM

Claim a staged recording before processing it, so a long call is never stored twice

FixConversionService
관련 상품
2026년 9월 28일 오전 2:53 UTC
이름 *
Kamo
뚱 베어
8a8d34c

DaemonService hands ConversionService every row that is still unprocessed: on its poll tick, on every voip.recording.received message (which does not wait for a batch in flight), and again after its 10-minute read timeout gives up on a batch still running here. Chunked transcription through AIService runs at about 0.4 x real time, so a call batch with more than ~24 minutes of audio outlasts that window, and the rows still in flight were converted, transcribed and stored a second time: a duplicate Img/Recording row and AUDIO_SECONDS metered twice. processOne now takes a Redis lease on the row (SET NX PX, random token) before reading it. The lease is renewed every third of its 5 minutes while the work runs, so a dead pod drops it within one lease; a worker past 4 hours stops renewing. Before storing, the worker checks it still holds the lease, and a failure is written to the row only while it does. A row another worker holds answers ok/inFlight untouched; Redis unreachable leaves the row for a later tick (fails closed, like SingletonTaskRunner). Redis, not a column: no DDL. **************** pins the failure scenario: a 3-recording, 30-minute batch dispatched again while its first recording is transcribing stores and transcribes each recording once (4 transcriptions without the claim). SP12 final review I2.

모든 변경 사항

배송을 보는 것과 같이?

모든 것이 자신의 작업 공간에서 도착합니다. 무료 플랜을 시작하고 이 페이지를 다시 한 달에 읽으십시오.

무료 영원히 시작가격 비교