Кратко

  • Итог FAILED может соседствовать с успешными операциями над отдельными объектами. В официальном примере из пяти объектов три операции меняют данные, одна успешно обходится без изменения, еще одна завершается ошибкой.
  • Обрыв HTTP-соединения сам по себе не отменяет обработку на сервере. Отсутствие ответа оставляет исход неизвестным для клиента, а не доказывает, что все осталось как было.
  • Уведомления зависят от адресатов и объектов. Решение о повторной попытке должно учитывать подробный ответ и разрешенную проверку состояния, а не только общий статус или полученное письмо.

Чему именно не удалось выполниться

Слово «неудачно» удобно для отчета о задании. Оно говорит, что желаемый результат достигнут не полностью. Но оно не отвечает на другой вопрос: какие изменения уже произошли? Для следующей попытки это порой важнее самого факта ошибки. Если считать все задание невыполненным в смысле «ничего не менялось», можно начать восстановление с состояния, которого уже нет.

В базе RIPE эта разница видна прямо из документации. На странице об ответах на обновление приведен пример с пятью распознанными объектами. Успешными названы четыре операции: создание одного объекта, изменение двух и один NOOP — операция, не меняющая данные, поскольку присланный объект уже совпадает с сохраненным. Еще одна попытка изменения заканчивается ошибкой.

Арифметика здесь важна. Четыре успеха означают три фактических изменения и одно подтверждение уже существующего состояния. Одна ошибка не превращает эти изменения в ноль. При этом для общего результата ответа в формате электронной почты документация указывает правило: достаточно хотя бы одной ошибки, чтобы получить FAILED.

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

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

Независимость имеет смысл

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

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

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

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

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

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

Когда связь оборвалась, а работа продолжилась

Транспортный ответ добавляет еще один уровень. Для Syncupdates документация допускает HTTP 200 при обработанном запросе, внутри которого были ошибки объектов. Значит, код ответа не заменяет чтение его содержания. Это указание относится к описанному поведению Syncupdates, а не ко всем HTTP-интерфейсам RIPE NCC без исключения.

В противоположном случае ответ вообще не доходит. Документация Syncupdates и обработки объектов поясняет, что закрытие соединения само по себе не прекращает работу на сервере. Обработка может дойти до завершения, хотя вернуть отчет через закрытое соединение уже невозможно.

Завершить обработку — не значит принять каждую операцию. Сервер может закончить оценку и получить смесь успешных результатов и отказов. Клиент, не увидевший ответа, этого не знает. Его корректная исходная позиция — «результат не подтвержден», а не «все отклонено» и не «все принято».

Такое различие мешает удобной, но необоснованной автоматике: повторять все после любого тайм-аута, считая, что первая попытка ничего не сделала. Повторение иногда окажется безвредным, но это не знание, которое принес обрыв соединения. Чтобы судить о конкретных объектах, требуются дополнительные сведения.

Смена интерфейса не создает неделимость сама собой. Syncupdates допускает несколько объектов в одном сообщении; REST API предлагает операции по объектам со своим форматом ответов XML или JSON. Несколько отдельных REST-запросов не становятся одной атомарной операцией только потому, что приложение относит их к одному заданию. Общий замысел организации по-прежнему нуждается в учете результатов отдельных действий.

Для этой статьи мы не вызывали тайм-ауты, не отправляли изменения и не измеряли длительность обработки. Из документации нельзя вывести частоту происшествий или назвать пострадавшего. Она позволяет установить более скромное, но полезное правило: конец соединения и конец обработки — разные события.

Письмо сообщает не обо всем

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

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

Отличаются и причины отправки. Обычное уведомление об успешном изменении и сообщение upd-to, связанное с неудачной аутентификацией, имеют разный смысл. Полученное письмо не доказывает успех всех операций; отсутствие письма у одного адресата не доказывает отсутствие изменений. Доставка почты здесь не исследовалась.

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

Повторить можно только определенное действие

Практический вывод не требует сложной новой системы. Для каждого задуманного объекта можно различать подтвержденное изменение, явный отказ, успешное отсутствие изменения и неизвестный исход. Затем связать результат с первоначальной операцией, временем, интерфейсом и последующей разрешенной проверкой. Это предлагаемая практика, выведенная из описанного поведения, а не новый обязательный формат RIPE NCC.

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

Предварительный dry-run проверяет синтаксис, бизнес-правила, авторизацию и ссылочную целостность без записи изменений. Он возвращает ответ о проверке, но не обычные уведомления об изменении. Это проверка намерения, а не резервирование будущего состояния. Ее успех не доказывает результат более поздней записи. Для этой работы dry-run в базе RIPE не выполнялся.

Через исторические данные доступны прежние версии объектов, но не исторические персональные данные. Граница публичного получения сведений не доказывает отсутствие внутренних журналов. Она также не оправдывает перенос контактов и секретов в общедоступные рабочие отчеты. Исходные ответы следует хранить с ограниченным доступом, а в оперативные выписки переносить только необходимое.

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

Источники

  1. RIPE NCC — Ответы на обновление
  2. RIPE NCC — Обработка объектов
  3. RIPE NCC — Syncupdates
  4. RIPE NCC — Сообщения уведомлений
  5. RIPE NCC — REST API базы RIPE
  6. RIPE NCC — Проверка без применения изменений
  7. RIPE NCC — Исторические данные