Web3-оракул: проверка схемы ответа внешнего API
Ответ асинхронной проверки теперь связан с нужным заданием. Но его тело всё ещё является внешними данными. HTTP 200, непустая строка и подлинный транспортный report отвечают на разные вопросы. В уроке определим допустимую схему результата и отделим техническое завершение от положительного вывода проверки.
Наш внешний сервис условно проверяет формат выпуска библиотеки. Он не оценивает абсолютное качество всех уроков и не управляет publisher базового CourseCatalog. Результат — самостоятельная модель декодирования и ошибок, без запроса API или выполнения consumer.
Технический ответ и смысл
HTTP-операция может успешно получить документ, содержащий отказ внешнего сервиса. Workflow может закончить предусмотренную обработку и сформировать report об ошибке. Прикладной статус выпуска в этих случаях не становится положительным только потому, что transport завершился.
Поэтому журнал сохраняет отдельные поля: получение состоялось, формат разобран, задача сопоставлена и смысл принят. Если API вернул HTML ошибки вместо JSON, это не отрицательная проверка содержания; схема вообще не получена. Если правильный JSON сообщает rejected, это другой результат, который должен быть понятен редактору.
Не используем приведение любого непустого значения к boolean. Строка "false" в некоторых языках логически истинна как непустая. Число 1 и строка "1" также не всегда имеют одинаковый смысл схемы. Типы и разрешённые значения определяются до декодирования прикладного статуса.
Собственная схема библиотеки
Введём результат library-release-check-v1, связанный с заданием и редакцией. Смысл положительного значения ограничен конкретной проверкой формата. Обязательство манифеста относится к тем же точным байтам, что у исходного задания, и не может быть заменено свободным значением ответа.
{
"schema": "library-release-check-v1",
"jobId": "library-check-edition-2",
"courseId": "17",
"edition": "2",
"manifestDigest": "EXPECTED_SHA256",
"result": "accepted",
"reasonCode": "FORMAT_SUPPORTED"
}Это образец собственного документа с меткой digest. Реальная схема задаёт допустимые типы, длины, идентификаторы и перечисление результатов. Она не является стандартным ответом CRE или любого внешнего API. Адаптер получает исходные данные и формирует только поддерживаемый нормализованный результат.
Проверка назначения
Сначала устанавливается доверенная транспортная граница и связь с заданием. Затем сопоставляются курс, редакция, ожидаемый манифест и цель. Документ другого назначения не становится допустимым только потому, что имеет то же поле result. Схема версии предотвращает случайное использование будущего несовместимого формата.
Если внешний API возвращает лишь короткое число, наш процесс всё равно должен связать его с определённым намерением. Нельзя позволять одному callback изменять любой текущий курс по значению из интерфейса. Связь назначения существует до ответа и хранится устойчиво.
Для бинарного onchain-report нужен однозначный согласованный формат, например определённые ABI-типы по выбранному consumer. Произвольный JSON не читается контрактом автоматически. Кодирование, порядок полей и версия схемы становятся частью договора между workflow и приёмником.
Ошибки получения
Сетевой тайм-аут означает неизвестный или незавершённый результат получения по выбранному маршруту. HTTP-ошибка может содержать технический код, а неверный тип тела — отдельную причину. Все они отличаются от положительно полученной проверки, которая отвергла формат выпуска.
Адаптер не сохраняет полное секретное тело ошибки в публичном событии. Токены и чувствительные сведения могут оказаться в ответе или конфигурации. Для оператора нужен ограниченный диагностический состав: идентичность, стадия и допустимый код причины. Подробное внутреннее исследование имеет другую границу доступа.
Повторяемость ошибки тоже имеет значение. Неверная схема текущего ответа обычно не исправится от немедленного повторения той же функции. Временная недоступность может иметь допустимый повтор по политике бюджета. Решение определяется причиной, а не одним универсальным catch.
Положительное значение с неправильной областью
API вернул accepted для старой редакции. Транспорт правильный, но текущий job относится к новой. Смысл результата не переносится. Можно сохранить наблюдение старого задания, а новое оставить незавершённым. Подмена expectedDigest значением внешнего документа скрыла бы этот конфликт.
Во втором сценарии API поддерживает новый статус warning, которого наш consumer не знает. Программа не приравнивает его к успеху только потому, что он не называется error. Неподдерживаемое значение приводит к предусмотренному отказу обработки или отдельной неопределённости. Обновление схемы выполняется управляемо.
В третьем результате заявлено «формат поддержан», но файл материалов отсутствует у хранителей. Проверка формата и доступность не равнозначны. Карточка библиотеки сохраняет раздельные основания и не называет одно короткое слово accepted доказательством готовности всего сайта.
Пределы обработки
Внешние данные могут быть чрезмерно большими или глубоко вложенными. Ограничения размера тела, числа полей, длины строк и времени действуют до доверенного использования. Подлинная подпись не отменяет стоимость декодирования и не делает любое содержание безопасным для памяти браузера или газа consumer.
Для учебного результата выбираем маленькую фиксированную схему. Свободный большой текст причины не передаётся в контракт, если достаточно определённого reasonCode и внутреннего журнала. Если требуется подробный отчёт, он хранится отдельным объектом с установленной идентичностью и доступом.
После декодирования отображение также имеет свою политику. Строка внешней ошибки не исполняется как HTML внутри личного кабинета. UI показывает контролируемый текст или допустимый код, сохраняя границу активного контента.
Схема должна определить и обработку повторённого имени поля. Обычный JSON-парсер может оставить одно из значений и скрыть неоднозначность исходного текста. Если разные участники интерпретируют такой ответ по-разному, согласованная передача не обеспечивает общего смысла. Поэтому допустимый вход ограничивается форматом, где нужные условия обнаруживаются до потери информации, а нормализованный report имеет определённое кодирование. Аналогично отсутствие обязательного поля не заполняется удобным accepted по умолчанию. Недостающий результат является отказом схемы, пока адаптер не получил предусмотренное значение.
Что действительно принято
Положительный результат означает лишь согласованное утверждение конкретной проверки о конкретных данных. Он не заменяет авторство издателя, оплату читателя, криптографическую сверку всех файлов или независимость архивных копий. Эти свойства относятся к другим журналам библиотеки.
В досье готовы версии схемы, типы, ограничения, допустимые результаты и реакции на ошибки. Ожидаемые случаи описаны, а parser, API и onchain-report не исполнялись. Первичные основы маршрута приведены в CRE consensus computing и consumer contracts. Далее ограничим стоимость и ресурсы этой процедуры, чтобы правильный отказ не превращался в бесконечный поток повторов.