В этом материале
Сбой проверяют в известной точке потока; после передачи содержимого новый запрос нельзя незаметно считать продолжением прежнего.
Построить управляемый upstream
Вместо отключения реального сервера в случайный момент создают локальный fake upstream с коротким заранее известным ответом. Он умеет остановиться до отправки заголовков, сразу после них или после выбранного события содержимого. Это позволяет отличить дефект обработки ошибки от нестабильности сети и случайной длительности генерации. Для каждого сценария сохраняют исходные байты, точку разрыва и ожидаемую классификацию. Fake не должен обращаться к платной модели или копировать реальные пользовательские данные. Его задача — воспроизвести транспортную последовательность, поэтому синтетический payload полезнее недетерминированной генерации, которую трудно оборвать повторно в той же самой точке.
Различать три границы
До заголовков сервис ещё может сформировать обычный HTTP ответ об ошибке. После фиксации заголовков доступные способы сигнализации меняются; после передачи содержимого клиент уже мог использовать частичный результат. Документация streaming OpenRouter описывает ошибки в уже начатом потоке, однако конкретный внешний формат не следует автоматически объявлять upstream-требованием каждого провайдера. Матрица теста отдельно хранит факт полученных заголовков, первого содержимого и terminal signal. Статус HTTP сам по себе не показывает полноту генерации: успешное начало соединения может закончиться повреждённым или незавершённым потоком. Эти наблюдения нельзя сворачивать в единственный флаг success на уровне транспорта.
Проверить framing и terminal state
В одном случае fake закрывает соединение без финального события, в другом отправляет допустимое сообщение об ошибке и корректно завершает транспорт. Для HTTP/1.1 полнота сообщения зависит от framing, описанного в RFC 9112. При этом корректно завершённое HTTP сообщение ещё не гарантирует завершения прикладной генерации. Тест проверяет оба уровня независимо. В отчёте указывают последний полностью разобранный SSE event и число уже переданных клиенту байтов. Если ожидаемая ошибка превращается в бесконечное ожидание, исследуют timeout и конечный автомат читателя, а не просто увеличивают время теста до исчезновения симптома.
Ограничить повторы и прокси
Прокси способен буферизовать данные, менять наблюдаемую точку разрыва или выполнять собственные повторные обращения. Документация nginx proxy помогает проверить соответствующие настройки конкретной установки. В локальном опыте сначала проверяют прямой путь, затем добавляют прокси и сравнивают события. Все попытки имеют общий максимальный бюджет и отдельные идентификаторы. Если часть ответа уже передана наружу, автоматический replay может продублировать содержимое или смешать две генерации. Тест должен обнаруживать такой результат, даже если второй upstream успешно ответил. Возможность fallback до видимого содержимого также проверяют явно, не предполагая её безопасной только по одному HTTP status.
Сохранить воспроизводимый сценарий
Артефакт включает версию fake, байтовый fixture, offset отказа, конфигурацию прокси, фактические попытки и итоговый статус клиента. Полезны ошибки streaming и fallback inference-маршрутизации. Набор ограничивают временем и количеством сценариев; намеренное повреждение работает только в тестовом контуре. Прохождение подтверждает обработку выбранных точек разрыва, а не устойчивость ко всем сетевым отказам или корректность удалённого движка. Для неожиданных различий сохраняют минимальный случай и отдельно проверяют, не изменил ли test harness порядок отправки событий. Это важнее большого отчёта с количеством случайных перезапусков.