Vidu API: polling budget и отмена ожидания без ложного статуса

Создайте локальную запись до первого запроса статуса

Сразу после запуска прикладное приложение создаёт свою запись задачи: tenant, локальный order ID, безопасный task reference, время создания и состояние pending. Не используйте task ID как идентификатор пользователя и не помещайте в него prompt, URL медиа, ключ или email. Эта запись остаётся источником правды для интерфейса, даже если внешняя проверка временно недоступна.

Пользователь видит понятный локальный статус, а не догадку на основе одного HTTP-ответа. Отдельно храните момент следующей разрешённой проверки и максимальное число попыток. Если задача была создана не подтверждённо, не генерируйте новый task ID ради повторного нажатия кнопки: сначала найдите исходную операцию и покажите путь сверки.

Задайте budget на весь цикл, а не бесконечный interval

Polling без границы создаёт нагрузку, скрывает сбои и заставляет интерфейс ждать дольше разумного. Установите локальный deadline для пользовательского ожидания, минимальный интервал и ограничение попыток. После каждого ответа вычисляйте оставшееся время; если budget исчерпан, прекратите активное ожидание и сохраните состояние needs_check, а не продолжайте запросы в фоне без объяснения.

Интервал можно увеличивать с ограниченным backoff и jitter, но это не должно быть обещанием скорости. Частота зависит от правил вашего приложения и текущего контракта маршрута. Не делайте вывод, что 404, timeout или пустой ответ означает окончательный провал задачи: это наблюдение нужно сопоставить с локальной записью и повторно проверить по безопасному процессу.

Отмена ожидания не равна отмене видеозадачи

Кнопка «не ждать» или закрытие вкладки прекращает только клиентское ожидание. Она не доказывает, что запрос уже не выполняется у внешней стороны. Интерфейс должен сказать это прямо: мы перестали опрашивать, но итог неизвестен и доступен через локальный task reference. Так пользователь не примет решение на основе ложного слова «отменено».

Если текущий API-контракт документирует операцию отмены, проверяйте её статус, ограничения и результат отдельно на staging. Даже успешный локальный вызов не следует переносить как обещание для другой модели или маршрута. До подтверждения сохраняйте состояние cancellation_requested, а после — сверяйте наблюдаемый итог. Для платных или рискованных сценариев добавьте ручную эскалацию вместо автоматического повторного запуска.

Защитите worker от дубликатов и старых ответов

Один task может оказаться в очереди несколько раз из-за рестарта worker, повторной доставки или действия пользователя. Перед polling worker берёт локальную блокировку по operation ID и проверяет версию записи. Ответ можно применить только если он относится к текущему task reference и ожидаемому состоянию. Поздний результат не должен перезаписывать решение, принятое после ручной сверки.

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

Проверяйте результат до сохранения и публикации

Финальный статус не заменяет проверку контента и безопасности. До сохранения оценивайте, что ссылка и тип данных соответствуют разрешённому процессу, а медиа проходят локальные правила доступа, прав и ручного одобрения. Не открывайте произвольный URL в привилегированном worker и не публикуйте результат только потому, что задача выглядит завершённой.

Сохраните минимум доказательств: локальный operation ID, время проверки, безопасный класс результата и кто подтвердил публикацию. Не записывайте полный prompt, cookie, Authorization или исходную ссылку на медиа в общий журнал. Подробнее о границе между техническим итогом и хранением — в статье срок хранения result URL.

Тестируйте конечные состояния без сети

Синтетический набор должен моделировать pending, поздний success, timeout, неизвестный формат, повторную доставку, закрытие окна и запрет на публикацию. Проверьте, что deadline прекращает polling, отмена ожидания не меняет внешнее состояние на «отменено», а повтор не создаёт новую задачу до сверки. Этот тест запускается без реального ключа и проверяет только код вашего приложения.

После изменения SDK, очереди, схемы или маршрута повторите staging-сценарий с обезличенными данными. Если контракт изменился, остановите rollout конкретного адаптера и покажите пользователю честный статус. Для выбора архитектуры полезно сопоставить polling и webhook для Video API; конкретные возможности подтверждайте по действующей документации перед release.

Безопасный server-side пример

Этот пример показывает только локальную логику приложения. Он не делает сетевой вызов, не содержит реальных ключей и не доказывает поддержку конкретного endpoint. Перед подключением рабочего маршрута сверяйте актуальный договор и API-контракт.

export function nextPoll({ createdAt, budgetMs, attempts, now = Date.now() }) {
  const remainingMs = createdAt + budgetMs - now;
  if (remainingMs <= 0) return { poll: false, state: 'needs_check' };
  if (attempts >= 8) return { poll: false, state: 'needs_check' };
  return { poll: true, delayMs: Math.min(30_000, 1_000 * (attempts + 1)), remainingMs };
}
// Local scheduling only: this does not call, cancel, or reveal any external API.

Граница ответственности и данных

Не передавайте в браузер, тикет, статью или обычный журнал API-ключи, заголовок Authorization, cookie, ключи поставщиков, полный prompt или персональные данные. Условия обработки данных, права на контент и применимые требования проверяются по политике организации, договору и с ответственным специалистом.

Контроль перед выпуском

Перед release проверьте синтетический сценарий, роли и tenant boundary, запреты на секреты в логах, понятный статус для пользователя и ручную ветку для неизвестного результата. Сохраните дату, версию адаптера и результат теста. После изменения SDK, модели, схемы или маршрута повторите проверку; старый прогон не подтверждает новый контракт.

Для выбора маршрута откройте RussiaAPI и сверяйте действующие условия в каталоге. Используйте только ключ своего аккаунта на сервере. RussiaAPI не является официальным представителем упомянутых поставщиков; доступность функций, цены, лимиты и правила обработки данных требуют отдельного подтверждения.

Полезные материалы

MDN: AbortController · AWS Builders Library: Timeouts, retries, and backoff with jitter

FAQ

Останавливает ли закрытие вкладки видеозадачу?

Нет. Закрытие вкладки прекращает только ожидание в интерфейсе. Сохраняйте локальный operation ID и показывайте пользователю способ проверить итог. Отмену внешней работы можно считать подтверждённой лишь после отдельной проверки текущего контракта и наблюдаемого статуса.

Какой интервал polling выбрать?

Нет универсального значения. Установите локальные границы: deadline, ограничение попыток, backoff и понятный статус после исчерпания budget. Затем проверьте фактические правила маршрута на staging. Частота polling не должна создавать бесконечную нагрузку или обещать срок результата.

Можно ли публиковать медиа сразу после success?

Не автоматически. Success описывает наблюдаемый технический статус, а не права, безопасность, качество или готовность к внешней публикации. Проверьте локальные правила, разрешённый тип данных и при необходимости назначьте ручное подтверждение.

Следующий шаг

Продолжите с материалами: Polling или webhook для Video API · Асинхронная генерация видео · Срок хранения result URL. Затем проверьте текущие условия и безопасно протестируйте интеграцию на staging перед production-трафиком.