- контекст проложен от воркера и обоих входов до внешних вызовов: ffmpeg и
ffprobe заводятся через exec.CommandContext, SpeechKit и Object Storage
принимают ctx вместо context.Background, скачивание записи идёт запросом с
контекстом. Прежде остановка сервиса не доходила до чужой работы вовсе
- прерванный шаг приговора не выносит: убитый по контексту ffmpeg отдаёт
«signal: killed», от настоящего отказа неотличимо ни типом, ни errors.Is, и
различает их только ctx.Err(). Задача остаётся на повтор, попытку не тратит и
отправителю о несуществующем сбое не сообщает; воркер не считает остановку
отказом, а задача не забирается вовсе, если нас уже остановили
- клиента Bot API заводит единая точка internal/adapter/telegram: токен стоит в
пути каждого обращения, а http.Client кладёт адрес в *url.Error целиком.
Чистка на месте употребления закрывала один вызов из пяти — теперь свой Do
чистит отказ, подменённый логгер вычищает токен из строк самой библиотеки, а
транспорт бота токена не получает вовсе
- принятие операции распознавания защищено от отмены своим пределом: SpeechKit
мог её принять и начать считать деньги, а потерянный идентификатор заставил
бы повтор оплатить ту же запись второй раз
- приём по HTTP доводит запись до задачи независимо от отправителя: на
контексте запроса один обрыв соединения терял полностью загруженную запись
- ответ Telegram с не-2xx кодом больше не становится записью: прежде тело
отказа доезжало до хранилища и умирало на ffprobe, уводя диагностику
av
f494dcb83e