Блокчейн-мост: задержки и восстановление доставки

Исходная публикация завершилась, сообщение получило идентичность, но целевой реестр ещё не обновлён. Веб-страница ждёт уже долго, и пользователь нажимает кнопку второй раз. Такой момент требует модели восстановления, а не простого повторения всей цепочки действий. В уроке продолжим журнал передачи объявления курса 17.

Мы не используем реальный мост и не выполняем ручное сообщение. Пример задаёт ожидаемые состояния собственного приложения с отдельным транспортным адаптером. Возможности повтора конкретного протокола исследуются по текущей документации, а не обещаются универсально.

Тайм-аут интерфейса

Время ожидания страницы является пользовательским ограничением. Оно не доказывает, что транспорт прекратил работу и никогда не доставит сообщение. Поэтому после тайм-аута локальный статус может быть «готовность пока не подтверждена». Само сообщение сохраняет свою идентичность и продолжает иметь предусмотренный жизненный цикл.

Если продукт решает больше не ждать данное объявление, это отдельная прикладная политика. Поздняя доставка всё ещё может случиться, и приёмник должен знать, допустимо ли применение. Иначе страница считает задачу отменённой, а целевой контракт незаметно обновляется позднее. Решение об отмене не возникает только из закрытия вкладки.

Возобновление наблюдения

Журнал сохраняет исходную сеть, целевую роль, messageId, назначение и последнее известное состояние. После перезапуска сервис продолжает наблюдение этого задания. Он не создаёт новую исходную операцию просто потому, что больше не видит старую анимацию ожидания.

сохранённое намерение
  → известная исходная операция
  → известный messageId
  → последний транспортный результат
  → отдельный результат целевого приложения

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

Неизвестная отправка

Запрос мог дойти до исходного механизма, а ответ потеряться. Повторный вызов способен создать второе сообщение того же объявления. Поэтому адаптер использует реальный способ сверки: известное исходное событие, идентификатор операции либо предусмотренный поиск. Нельзя придумывать серверную идемпотентность, которой выбранный API не обеспечивает.

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

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

Отказ целевого исполнения

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

Диагностика различает ресурсное ограничение, административную конфигурацию и прикладную недопустимость. Для каждой причины есть понятное решение: корректный профиль ресурса, согласованное изменение конфигурации либо новое правильное объявление. Самовольная замена digest в уже сохранённой истории разрушила бы связь с исходным выпуском.

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

Поздний результат старой редакции

Пока первая попытка ожидалась, библиотека подготовила более новую редакцию. Позднее пришло старое сообщение. Приёмник применяет установленное правило: историческое объявление можно сохранить, а текущую рекомендацию не понизить случайно. Веб-интерфейс не сопоставляет ответ только по courseId, потому что одно число курса относится ко многим заданиям.

Для каждого задания нужны редакция, полезная нагрузка и ревизия конфигурации. Если административное право источника изменено между отправкой и доставкой, процедура определяет допустимость старой попытки. Это решение нельзя вывести из времени получения страницы. Оно относится к политике целевого приложения.

Аналогично поздний обратный сигнал не должен менять карточку другого запроса. Обработчик сравнивает назначение и идентичность перед обновлением интерфейса. Частично завершённая история остаётся полезной для расследования, даже если продукт уже выбрал новое текущее объявление.

Сверка после восстановления сервиса

Сервис сравнивает сохранённые задания с предусмотренным транспортным источником и целевым состоянием. Если messageId завершён, но серверный статус старый, проекция обновляется. Если известен только целевой эффект, сохраняют основание такого наблюдения, не выдумывая отсутствующий промежуточный лог.

При пересмотре сетевой истории результаты могут потребовать нового анализа. Журнал связывает наблюдения с контекстом, а не хранит единственный вечный флаг. Источник, выбранный блок и свежесть помогают различить задержку RPC, реорганизацию и неверный адрес экземпляра.

Для библиотеки при восстановлении важно также не потерять архив материалов. Исправление межсетевого статуса не требует заново выпускать HTML. Сохранённые манифесты и корни помогают удержать точную идентичность даже при временно неизвестной доставке объявления.

Повторное исполнение может требовать отдельного ресурса или оплаты по выбранному механизму. Поэтому операторская процедура имеет предел попыток и основание для каждого действия. Она не превращается в бесконечный цикл, который посылает транзакции, пока интерфейс не нарисует успех. Если причиной является детерминированная ошибка схемы, повтор без изменения условий лишь воспроизводит отказ. Если состояние неизвестно, сначала нужно обновить наблюдение. Разделение причины и действия сохраняет исходную идентичность задания и позволяет объяснить затраты. Условия текущего транспорта исследуются отдельно от цены первоначальной операции A.

Правило завершения

Задание считается прикладно завершённым по выбранному критерию целевого применения, а не по истечению таймера. Если критерий достигнут, повторное наблюдение не повторяет действие. Если задача окончательно отвергнута, причина и границы сохраняются; новое объявление получает свою историю. При неизвестном результате интерфейс не использует категоричное «не было отправлено».

Ожидаемые случаи: потерянный ответ восстанавливается сверкой, ресурсный отказ исследуется по протоколу, старое сообщение не откатывает новую редакцию, перезапуск не создаёт новое намерение автоматически. Фактические действия не исполнялись. Первичный пример состояний дан в CCIP Message Lifecycle. Далее перейдём к оракулам, где асинхронность дополняется ещё одной границей: смыслом внешних данных.

Оглавление серии