KamoCRM

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

FixConversionService
Змішані
28 вересня 2026 р. о 02: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.

Всі зміни

Як ви бачите відправлення?

Все це прибуває в робочому просторі. Почати безкоштовно план і читати цю сторінку знову в місяць.

БезкоштовноПерегляд цін