KamoCRM

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

FixConversionService
Expediere
28 septembrie 2026 la 02:53 UTC
Autor
Kamo
Comite
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.

Toate modificările

Ca ceea ce vezi de transport maritim?

Toate acestea ajung în spațiul de lucru pe cont propriu. Începeți cu planul gratuit și citiți această pagină din nou într-o lună.

Pornește gratuit pentru totdeaunaVezi prețurile