# Как заменить опрос и вебхуки Replicate Predictions в существующем приложении? > Поместите независимую от провайдера асинхронную запись задания между продуктом и API. Направьте проверенные вебхуки и ограниченный опрашивающий worker в один идемпотентный финализатор, нормализуйте состояния и копируйте готовые файлы в постоянное хранилище. Поместите независимый от провайдера слой заданий между приложением и API инференса. Нормализуйте создание, состояние, отмену, события завершения и сохранение результатов, чтобы продукт не зависел от объектов и URL Replicate. Не меняйте только callback URL в коде продукта. Сначала определите необходимый асинхронный контракт. ## Зафиксировать текущее поведение Асинхронное создание Replicate возвращает ID prediction, состояние и вспомогательные URL. Приложение может опрашивать `urls.get`, получать POST webhook или использовать серверные события. Запишите путь каждого процесса и действие продукта при каждом переходе. | Понятие Replicate | Замена в приложении | |---|---| | ID prediction | ID задания провайдера и внутренний ID | | `starting`, `processing` | `queued`, `running` | | `succeeded` | `completed` | | `failed`, `canceled` | `failed`, `canceled` | | `urls.get` | Метод состояния адаптера | | Нагрузка webhook | Нормализованное событие завершения | | URL результата | Постоянный ресурс приложения | Храните исходное состояние провайдера отдельно от нормализованного, чтобы диагностировать различия жизненного цикла. ## Ввести внутреннюю запись задания Создайте строку в базе до вызова нового провайдера: ```json { "job_id": "job_01J...", "provider": "target", "provider_job_id": null, "state": "creating", "attempt": 1, "output_assets": [] } ``` Используйте внутренний `job_id` в интерфейсе, очередях и уведомлениях. Добавьте внешний ID после создания. Ключ идемпотентности предотвращает запуск двух платных заданий из-за сетевого повтора. ## Заменить опрос ограниченным worker Если цель позволяет читать задания, но не поддерживает webhook, перенесите опрос в фоновый worker. Используйте экспоненциальную задержку с jitter, срок и максимальный интервал. Останавливайтесь при любом конечном состоянии, включая отмену. Не опрашивайте из браузера. Серверный worker продолжает работу после закрытия вкладки, централизует лимиты и транзакционно сохраняет переходы. ## Заменить вебхуки проверенными событиями Держите обработчик небольшим: * проверяйте подпись или общий секрет до разбора; * удаляйте дубликаты по событию или заданию и состоянию; * быстро отвечайте и ставьте обработку в очередь; * при частичной нагрузке запрашивайте официальное задание; * допускайте повторную и неупорядоченную доставку. Replicate фильтрует start, output, logs и completed. Цель может отправлять только конечные события. Не создавайте ложную точность прогресса. ## Использовать единый путь завершения Опрос и webhook вызывают один идемпотентный финализатор. Он блокирует внутреннее задание, проверяет внешний ID, сохраняет конечный статус, копирует файлы в постоянное хранилище и публикует одно событие. Это устраняет двойные уведомления, когда webhook и последний опрос приходят вместе. ## Сохранять файлы до их исчезновения Replicate указывает, что файлы входов и результатов API prediction удаляются через ограниченное время. У цели могут быть другие сроки хранения и жизни URL. Считайте внешние URL способом доставки, а не постоянным хранилищем. Быстро скачивайте результаты, проверяйте тип и размер, при необходимости сканируйте, сохраняйте под собственным ключом и записывайте контрольную сумму. Клиентам выдавайте собственный стабильный URL. ## Проверить сбои и восстановление Тестируйте задержанное создание, повторные и пропущенные вебхуки, 429 и 5xx, гонки отмены, истекшие URL, неверные нагрузки и перезапуск worker во время задания. Запускайте оба адаптера в теневом режиме с безопасными входами. Сравните конечные состояния и число ресурсов до переноса небольшой доли трафика. ## Итог Надежная замена — внутренний контракт асинхронного задания, а не разбросанные callback. Нормализуйте состояния, делайте финализацию идемпотентной, сразу сохраняйте файлы и направляйте проверенный webhook или ограниченный worker в один путь завершения. ## FAQ ### Должен ли браузер напрямую опрашивать новый API? Лучше использовать серверный worker. Он продолжает работу после закрытия браузера, централизует ограничения и повторы и согласованно обновляет внутреннее состояние. ### Как сопоставить состояния prediction в Replicate? Сведите их к небольшому внутреннему циклу: creating, queued, running, completed, failed и canceled, сохранив исходное состояние для диагностики. ### Как предотвратить двойную обработку webhook? Проверяйте подлинность, устраняйте дубликаты по событию или заданию и состоянию и направляйте webhook и опрос в один транзакционный идемпотентный финализатор. ### Что делать, если новый провайдер не поддерживает вебхуки? Используйте фоновый worker с экспоненциальной задержкой, jitter, сроком ожидания и явной обработкой всех конечных состояний. ### Можно ли постоянно показывать пользователям URL результатов провайдера? Не рассчитывайте на их постоянство. Быстро скачивайте результаты и предоставляйте собственные URL ресурсов со своим контролем доступа. ### Какие сбои нужно покрыть тестами? Проверьте повторные и пропущенные события, ограничения, временные ошибки, гонки отмены, истекшие результаты, неверные нагрузки и перезапуск worker.