- контекст проложен от воркера и обоих входов до внешних вызовов: 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, уводя диагностику
- записи, метаданные и файлы съехались под один каталог данных; появилась
панель владельца, а gin, goqu, goose и требование CGO ушли
- захват задачи стал одним запросом с RETURNING; заведены число попыток,
состояние dead и нарастающая пауза вместо признака is_error
- имя файла в хранилище задаёт сервис и в журнал не идёт: вместе с
идентификатором записи оно собирало бы ссылку на скачивание
av