Fallback для аудио должен покрывать реальные ошибки декодирования

Симптом

У части пользователей аудиофайлы не распознавались, хотя те же файлы воспроизводились. В Telegram их длительность отображалась как 00:00, а другие файлы формата m4a обрабатывались нормально.

Контекст

Сервис сначала определял длительность аудио через pydub, а затем передавал файл на расшифровку. Для проблемных файлов pydub не мог корректно прочитать метаданные, поэтому до этапа распознавания выполнение не доходило.

Корневая причина

После ошибки pydub функция завершалась исключением вместо перехода к fallback через ffmpeg. Обработчик учитывал только IndexError, хотя библиотека могла выбрасывать и CouldntDecodeError.

Ошибочное предположение

Мы предполагали, что если pydub не сможет определить длительность, это всегда будет один и тот же тип ошибки. Поэтому fallback покрывал только известный сценарий и не срабатывал для других ошибок декодирования.

Обнаружение

Проблема обнаружилась при отладке конкретных файлов: они воспроизводились, но получали нулевую длительность и не проходили в распознавание. Сравнение с обычными m4a показало, что сбой зависел от особенностей файла, а не только от его расширения.

Исправление

Обработчик расширили так, чтобы учитывать CouldntDecodeError и использовать fallback через ffmpeg для ошибок, которые означают, что pydub не смог декодировать файл.

Fallback остаётся ограниченным границей декодирования: если ffmpeg тоже не может прочитать файл, сервис возвращает явную ошибку, а не скрывает проблему.

Проверка

Проверили исходные проблемные файлы и обычные аудиофайлы. Регрессионный набор должен включать оба класса: файлы, которые успешно обрабатываются через pydub, и файлы, для которых требуется fallback через ffmpeg.

Общий вывод

Если fallback закрывает реальный класс ошибок, его нельзя ограничивать одним предполагаемым исключением. Лучше покрыть всю осмысленную границу отказа, сохранив явную ошибку, если резервный путь тоже не сработал.