API вернул 202 Accepted, но отчёт не появился или импорт не завершился. Этот код означает, что запрос принят в обработку; он не обещает успешного выполнения. По RFC 9110, операция может впоследствии вообще не выполниться.
Чтобы узнать результат, найдите ID операции и предусмотренный API способ проверки статуса. Дождитесь конечного состояния и проверьте сам результат: созданный файл, запись или изменение данных. Повторять исходный запрос только из-за долгого ожидания опасно — можно запустить вторую работу.
1. Найдите подтверждение именно вашей операции
В ответе на запуск ищите идентификатор задачи и ссылку проверки: например, поле statusUrl в JSON или заголовок Location. Названия и расположение зависят от контракта API; HTTP 202 сам по себе не требует именно этих полей и не заставляет браузер перейти по ссылке.
Сохраните время запуска с часовым поясом, ID операции и идентификатор запроса для поиска в логах. Сравнивайте запросы к одному окружению и той же учётной записи: статус похожей задачи в тестовом сервисе ничего не скажет о рабочем импорте.
Если в ответе нет ни ID, ни инструкции получения результата, проверьте документацию интеграции. Из одного кода 202 восстановить исход операции нельзя; нужен предусмотренный сервисом канал — статусный endpoint, callback или журнал заданий.
2. Читайте статус в теле, а не только HTTP-код
Условный ответ сервиса может выглядеть так:
HTTP/1.1 202 Accepted
Location: /api/jobs/example-job
Retry-After: 5
Content-Type: application/json
{"jobId":"example-job","status":"queued"}Здесь queued — ожидание обработки. Последующий GET по адресу проверки может вернуть HTTP 200 и {"status":"running"}: успешно прочитан статус, но работа ещё идёт. Это пример контракта, а не обязательный формат для всех API.
В шаблоне асинхронного обмена Microsoft отдельно описаны запуск, опрос состояния и получение результата. Для конкретной интеграции выпишите её значения:
- Промежуточные: задача ожидает или выполняется — наблюдение продолжается.
- Успешное конечное: обработка завершена — можно проверять результат.
- Неуспешные конечные: ошибка или отмена — нужен разбор причины.
Незнакомый статус нельзя автоматически считать успехом. Также различайте ошибку чтения статуса и ошибку самой задачи: HTTP 503 у статусного endpoint не доказывает, что обработчик завершился неудачно.
3. Ограничьте ожидание и частоту опроса
Если контракт предусматривает Retry-After, учитывайте его при следующем запросе. В примере выше значение означает паузу в пять секунд; это не гарантия, что через пять секунд появится готовый файл. При отсутствии подсказки задайте ограниченный интервал по документации сервиса и увеличивайте паузу при повторных временных ошибках.
Заранее определите предельное ожидание по требованиям операции. После его истечения отметьте «результат пока неизвестен», сохраните ID и передайте задачу на разбор. Истечение тайм-аута клиента не отменяет работу на сервере.
Повторный POST допустим только по правилам API: сначала выясните судьбу исходной операции и условия идемпотентности. Подробности разобраны в руководстве по повтору запроса без дублей.
4. Если задача зависла, найдите участок остановки
Для владельца сервиса полезна последовательность «приём → очередь → обработчик → сохранение результата». Проверяйте её по одному ID операции, не создавая новые задания ради диагностики.
Долго остаётся в очереди
Сопоставьте запись о принятии с фактом постановки в очередь и получением задания обработчиком. Проверьте, запущен ли worker, какую очередь он слушает и нет ли роста возраста ожидающих задач. Сам ответ 202 не является доказательством надёжной записи сообщения.
Выполняется без видимого прогресса
Найдите последнее подтверждённое действие обработчика: запрос к базе, внешнему API или запись файла. Сравните логи и время изменения статуса; отсутствие обновления может означать как зависшую работу, так и сломанный механизм отчётности. Не завершайте процесс вслепую, пока не понятны последствия повторного выполнения.
Статус не удаётся получить
При 401/403 проверьте права на чтение этой операции, при 404 — окружение, ID и срок хранения статусов. Для внешней интеграции передайте провайдеру обезличенный ID и время запуска. Не отправляйте токены, Cookie, подписанные ссылки и содержимое клиентских данных.
5. Подтвердите результат и отделите его от доступности API
Конечный статус должен соответствовать задаче пользователя. Для выгрузки проверьте, что файл доступен и содержит ожидаемые данные; для импорта — что нужные записи применены, а пропущенные отражены в отчёте. Если контракт допускает частичный успех, учитывайте его отдельно от полного завершения.
Внешний HTTP-мониторинг полезен для доступности безопасного URL. В Web-Puls можно контролировать такой адрес регулярно, но это не заменяет проверку жизненного цикла приватной задачи и её бизнес-результата.
Начните с одного незавершённого задания: свяжите исходный 202, ID, последнее состояние и ожидаемый результат. Если этой связки нет, согласуйте контракт проверки статуса с разработчиком; для выбора безопасной внешней точки используйте руководство по мониторингу API.