2.4.1: голосовое загружается, но сервер не доводит обработку до конца — video.not.ready

[azatsh]

Кратко

В 2.4.1 отправка голосового доходит дальше, чем в 2.4.0, но по-прежнему не работает.

upload_voice заливает аудио, получает HTTP 200 — и следующий за этим MSG_SEND сервер
отклоняет:

Key: errors.process.attachment.video.not.ready [errors.process.attachment.video.not.ready]

Похоже, сервер принимает байты, но никогда не переводит вложение в состояние «готово».
Ожидание не помогает: я вставлял паузу между загрузкой и отправкой (то есть внутрь
upload_voice, перед return) — 5 секунд, затем 15 секунд, и повторял всю попытку заново.
Суммарно больше 30 секунд ожидания на одно голосовое — ответ всё тот же not.ready.

Параллельно NOTIF_ATTACH (opcode 136) для голосовой загрузки не приходит вообще, ни разу, ни
через минуту. Для File в той же сессии и по тому же соединению он приходит меньше чем за секунду.

Окружение

maxapi-python	2.4.1 (и 2.4.0 до неё)
Python	3.12, Linux (Docker)
Сервер	api.oneme.ru
Аккаунт	обычный пользовательский
Аудио	голосовые из Telegram: Opus в контейнере Ogg, 29–57 КБ, длительность передаётся явно

Логи снимались с ExtraConfig(log_level="DEBUG").

Что в 2.4.1 стало заметно лучше

Спасибо за исправление — по логам видно, что диагноз изменился:

• 2.4.0 отвечал errors.process.attachment.video.not.supported — форма payload была не та.
• 2.4.1 отвечает errors.process.attachment.video.not.ready — форма уже принимается, дело
  теперь в незавершённой обработке.

То есть переход на VoiceAttachPayload (с duration и wave) сервер устраивает.

Воспроизведение

await client.send_message(
 chat_id=...,
 text="тест",
 attachments=[Voice(raw=ogg_bytes, name="voice.ogg", duration=3400)],
)

ogg_bytes — обычное голосовое из Telegram (Opus/Ogg). Воспроизводится каждый раз, на разных
файлах и разной длительности.

Хронология из логов

1. В 2.4.0 уведомление не приходит вовсе

16:39:49 Voice upload waiter registered voice_id=3698883559635
16:39:49 Voice upload HTTP response status=200 voice_id=3698883559635
16:39:49 Waiting for voice processing notification voice_id=3698883559635
 [следующие 60 с: только opcode=49 (CHAT_HISTORY) и opcode=1 (PING)]
16:40:49 Timed out waiting for voice processing notification voice_id=3698883559635

Для сравнения — загрузка File минутой позже, в той же сессии:

16:40:49 File upload waiter registered file_id=4760217947
16:40:50 File upload HTTP response status=200 file_id=4760217947
16:40:50 dispatching event type=EventType.FILE_READY
16:40:50 calling handler event=EventType.FILE_READY callback=UploadService.on_file_attach
16:40:50 File upload waiter resolved file_id=4760217947

За весь прогон opcode 136 встретился ровно один раз — вот этот, файловый.

2. В 2.4.1 отправка отклоняется сразу

15:05:34 Uploading voice
15:05:35 MAX rejected the voice note (errors.process.attachment.video.not.ready)

3. Пауза между загрузкой и отправкой не помогает

Обёрнутый upload_voice, который спит перед return (то есть MSG_SEND уходит уже после паузы),
15 секунд, две полные попытки подряд — каждая со своей загрузкой и своей паузой:

15:35:18 Uploading voice (пауза 15 с, затем отправка → not.ready)
15:35:36 Uploading voice (пауза 15 с, затем отправка → not.ready)
15:35:51 rejected: errors.process.attachment.video.not.ready

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

Наблюдение: User-Agent в голосовой загрузке закодирован percent-encoding

Не утверждаю, что это причина, но это единственное, чем заголовки голосовой загрузки отличаются от
остальных. api/uploads/service.py:

user_agent = (
 f"OKMessages/{self.app.config.app_version}"
 + f" ({self.app.config.device.user_agent.os_version};"
 + f" {self.app.config.device.user_agent.device_name};"
 + f" {self.app.config.device.user_agent.screen})"
)

headers = {
 "Content-Disposition": f"attachment; filename={quote(voice.name)}",
 ...
 "User-Agent": quote(user_agent), # <- целиком через quote()
}

quote() применяется ко всей строке User-Agent, и на выходе получается:

OKMessages/26.27.1%20%28Android%2013%3B%20Samsung%20SM-A525F%3B%20405dpi%20405dpi%201080x2400%29

Пробелы, скобки и точки с запятой экранированы — настоящий клиент такой заголовок не отправляет.
Для filename внутри Content-Disposition строкой выше quote() уместен, для User-Agent
целиком — вряд ли.

Что делает это наблюдение любопытным: голосовая загрузка — единственная из трёх, которая вообще
шлёт User-Agent. upload_video и upload_file его не отправляют, и обе работают. И именно
голосовая — единственная, обработку которой сервер не завершает.

Что проверено и можно не перепроверять

• Аудио валидное: контейнер Ogg (сигнатура OggS), Opus, из Telegram без перекодирования.
• Загрузка проходит: POST отвечает 200, в логе нет Voice upload failed with status.
• Дело не в размере: 29–57 КБ.
• Дело не в длительности: duration передаётся явно, в миллисекундах.
• Дело не в отсутствии bytes в Content-Range: в upload_file он тоже без префикса
  (f"0-{file_size - 1}/{file_size}"), и файлы загружаются нормально. Так что исправление этого
  префикса в голосовой ветке, скорее всего, было не тем, что чинило проблему.
• Дело не в нехватке времени: больше 30 секунд ожидания суммарно, результат не меняется.

Мелочь на будущее

В 2.4.1 ожидание убрано (закомментировано), но вокруг него остался мёртвый код: on_voice_attach
и очистка voice_upload_waiters в finally. Если ожидание когда-нибудь вернут, стоит учесть, что
регистрация и разрешение waiter-а шли по разным ключам: upload_voice клал future в
voice_upload_waiters[video_id], а on_voice_attach искал по attach.audio_id. Плюс
resolve_attach определяет тип фрейма перебором FileUploadSignal → VideoUploadSignal →
AudioUploadSignal, и у всех моделей extra="allow" — значит payload с videoId совпадёт с
VideoUploadSignal первым и уйдёт в on_video_attach. Это вывод из чтения исходников, а не
наблюдение: подходящего фрейма мы так и не увидели.

Вопросы

1. Работает ли отправка голосовых у вас сейчас, на актуальном сервере? Если да — очень поможет
   узнать версию приложения/сборки, под которую клиент представляется.
2. С какого клиента снимался протокол голосовой загрузки? Веб-версия MAX голосовые записывать не
   умеет (в меню вложений только «Фото или видео», «Файл», «Контакт», «Опрос», и микрофона в
   поле ввода нет), так что, видимо, с мобильного — и, возможно, с тех пор что-то поменялось.
3. Стоит ли ждать NOTIF_ATTACH для голосовых в принципе, или у аудио другой путь
   подтверждения? В pymax.protocol.Opcode не занят код 85 (между VIDEO_PLAY=83 и
   FILE_UPLOAD=87) — это ни на что не намекает, просто бросилось в глаза.

Готов снять любые дополнительные логи — DEBUG со стороны PyMax включается одной строкой, и
воспроизводится это стабильно.

[ink-developer]

Не правильный формат головосовго. Я в доках все писал

[ink-developer]

https://docs.pymax.org/files.html#voice-videonote

[azatsh]

Спасибо за ответ. Я перечитал документацию — и хочу уточнить, потому что, кажется, дело не только в формате.

Что говорят доки про формат

Единственное требование к формату Voice во всей документации (проверил все .rst в docs/ на main) — в docs/files.rst:

Для Voice используйте готовый OGG-файл. Простого переименования MP3, WAV или другого аудиофайла в .ogg недостаточно: PyMax загружает исходные байты без перекодирования.

Для VideoNote рядом расписано всё до кодека, разрешения, FPS и GOP. Для Voice — только «готовый OGG». Ни кодека (Opus / Vorbis), ни частоты, ни каналов, ни битрейта.

Мой файл — настоящий Ogg, не переименованный: сигнатура OggS, внутри Opus, это голосовое из Telegram без какой-либо обработки. Если у Max есть более узкое требование (например, только Vorbis, или Opus с конкретной частотой/моно), подскажите, пожалуйста, какое именно — я добавлю это в files.rst PR-ом, чтобы следующему человеку не пришлось выяснять это через not.ready.

Вторая проблема, независимая от формата: retry на not.ready не срабатывает

В 2.4.1 (и на main) есть именно та логика, что описана в release notes — «если отправка получает attachment.not.ready, PyMax ждёт событие готовности до 60 секунд и повторяет запрос один раз». Но она сравнивает ключ буквально:

# src/pymax/api/messages/service.py, send_message (и то же в edit_message)
except ApiError as e:
 if e.error == "attachment.not.ready":
 await self._process_attachment_error(attaches)
 response = await self.app.invoke(Opcode.MSG_SEND, frame.to_payload())
 else:
 raise

А сервер на голосовое отвечает другим ключом:

error: errors.process.attachment.video.not.ready
message: Key: errors.process.attachment.video.not.ready

ApiError.error — это сырой MaxApiError.error без нормализации (app.py, _build_api_error), так что "errors.process.attachment.video.not.ready" == "attachment.not.ready" — False, и ветка уходит в raise. В логах это видно по времени: отклонение приходит через ~1 секунду после отправки, никакого 60-секундного ожидания не происходит.

То есть заявленный retry на not.ready для голосовых сейчас мёртвый код — независимо от того, правильный у меня формат или нет. С правильным форматом он тоже не сработает, если отправка обогнала обработку.

Скорее всего, хватит e.error.endswith("attachment.not.ready") или проверки на .not.ready в ключе. Могу прислать PR.

Я посмотрел, что за файл отдаёт сам Max

Открыл голосовое в веб-версии Max и вытащил его из HAR (a.oneme.ru/audio, audio/ogg, 206):

Сравнил его с голосовым, записанным в Telegram — именно с тем файлом (29 681 байт), который сервер отклонил с not.ready:

	голосовое из Max	голосовое из Telegram (его я и шлю)
контейнер	Ogg	Ogg
кодек	Opus	Opus
каналы	1	1
частота	48000 Hz	48000 Hz
pre-skip	312	312
mapping family	0	0
длина фрейма	20 мс (granule step 960)	20 мс (granule step 960)
vendor	libopus unknown	libopus unknown-fixed

Совпадает всё, кроме строки vendor в OpusTags — а это свободный текст, который отличается лишь тем, что Telegram собирает libopus в fixed-point. Ни контейнер, ни кодек, ни моно, ни частота, ни pre-skip, ни длина фрейма не отличаются.

Оговорюсь про происхождение файла Max: он взят из веб-версии (a.oneme.ru/audio, audio/ogg, 206), то есть это то, что Max отдаёт на воспроизведение. Теоретически это может быть серверный транскод, а не то, что заливал клиент. Но если Max сам и принимает, и раздаёт Ogg/Opus 48k mono 20 ms — трудно понять, чем мой файл в этом формате хуже.

Если разница всё-таки в чём-то, чего не видно в заголовках (битрейт, VBR/CBR, комплексность, что-то в самих пакетах) — скажите, в чём именно, и я проверю. Пока по всем измеримым параметрам файлы одинаковые.

Я починил это сравнение у себя — и получил ответ на главный вопрос

Пропатчил e.error локально, чтобы ваша ветка not.ready действительно сработала. Она сработала: _process_attachment_error дождался своей очереди и честно прождал все 60 секунд. Событие готовности так и не пришло.

20:36:24 Uploading voice
20:36:24 Voice upload HTTP response status=200 voice_id=3745384759507
20:36:24 api error opcode=64 error=errors.process.attachment.video.not.ready
 ← здесь включается ваш retry и уходит ждать NOTIF_ATTACH
20:37:24 Timed out waiting for video processing notification video_id=3745384759507
20:37:25 dispatching event type=EventType.FILE_READY ← а это уже NOTIF_ATTACH для FILE, ~1 с

Ровно 60 секунд между отправкой и таймаутом — то есть ожидание отработало полностью. За это время NOTIF_ATTACH (opcode 136) не пришёл ни одного раза: во всём логе он встречается однажды, и это подтверждение файловой загрузки, которая пришла меньше чем за секунду по тому же соединению.

Так что дело не в том, что отправка обгоняет обработку. Для голосовых сервер, похоже, не присылает событие готовности вообще — по крайней мере для той загрузки, которую делает PyMax 2.4.1. Загрузка при этом уходит на аудио-эндпоинт и принимается:

https://au.oneme.ru/uploadAudio?cid=3745384759507&userId=...&clientType=33&signatureToken=...
HTTP 200

До этого я пробовал и просто ждать между загрузкой и MSG_SEND (внутри одного вызова, без повторной загрузки): 5 секунд, потом 15 секунд, две полные попытки. Каждый раз not.ready.

Мелочь на посмотреть

В upload_voice заголовок User-Agent целиком проходит через quote():

"User-Agent": quote(user_agent),

и уходит на сервер как OKMessages/26.27.1%20%28Android%2013%3B%20Samsung...%29. upload_video и upload_file User-Agent не шлют вовсе и работают. Не утверждаю, что это причина, но это единственное, чем заголовки голосовой загрузки отличаются от остальных.

Что могу сделать со своей стороны

Сравнить голосовое, записанное в самом приложении Max, с телеграмовским по кодеку/частоте/каналам и прислать сюда таблицу — если разница есть, это и будет ответ на вопрос о формате, и его можно будет записать в доки. Если подскажете, чем записывался ваш тестовый .ogg (или пришлёте команду ffmpeg, которой его готовили), сравню сразу с ним.