Краткий ответ
Не начинайте восстановление с кнопки «повторить». Сначала определите, успела ли удалённая сторона выполнить операцию, какой тип сбоя возник и можно ли проверить существующий результат по внешнему идентификатору. После этого выбирайте retry, управляемый replay или reconciliation; если состояние неизвестно, автоматический повтор может быть опаснее самой ошибки.
Применимость
Инциденты SPL относятся к реализации на Odoo 18 Community. Поведение XML-RPC сверено с документацией Odoo 18, а общие возможности очереди — с документацией OCA queue_job 18.0.
Классификация сбоев
Ниже — инженерная классификация автора. Не все категории встречались в SPL; она нужна для выбора реакции, а не для отчёта о конкретном проекте.
- Сетевой или транспортный сбой
- Тайм-аут, разрыв соединения, временная недоступность конечной точки.
- Ошибка аутентификации
- Неверные или отозванные учётные данные, отсутствие доступа к базе или конечной точке.
- Несовпадение схемы
- Поле, тип или структура данных не соответствует фактической реализации.
- Несовместимость API или метода
- Удалённый вызов обращается к отсутствующему методу или изменившемуся контракту.
- Ошибка исходных данных
- Исходная запись неполна или нарушает требования принимающей системы.
- Бизнес-конфликт
- Состояния систем корректны по отдельности, но противоречат согласованному процессу.
- Частичное выполнение
- Часть действий завершилась, а общее задание вернуло ошибку.
Опыт проекта: два инцидента SPL
Атрибуция
Примеры обезличены и относятся к опыту Владислава Червякова во время работы в kt.team. Они не означают, что SPL был клиентом текущей студии.
Случай A: несовпадение поля складского движения
Задание queue_job для синхронизации складских данных ожидало stock.move.line.qty_done, тогда как фактическая реализация в одном из контуров работала с quantity. Несовпадение проявилось во время выполнения задания. Это пример конкретного сбоя, а не описание модели stock.move.line во всех версиях Odoo.
Случай B: отсутствующий метод на принимающей стороне
Другой удалённый вызов обращался к методу, которого не было в модели product.product на стороне marketplace. Ошибку обнаружили по сбою задания очереди и RPC. После диагностики интеграционный вызов привели в соответствие с фактически доступным методом обновления остатков.
Архитектура и общий контекст проекта описаны в кейсе синхронизации двух Odoo для SPL.
Таблица решений при сбоях
Это инженерная памятка, а не описание настроек SPL. Безопасность автоматического retry зависит от побочных эффектов конкретной операции и от того, известно ли состояние принимающей системы. Риск дубля также определяется этим состоянием, а не только типом ошибки.
| Тип сбоя | Как обнаруживается | Автоматический retry | Действие оператора | Условие риска дубля |
|---|---|---|---|---|
| Транспортный тайм-аут | Тайм-аут или сетевая ошибка | Только при проверяемом результате или идемпотентной операции | Проверить доступность и состояние получателя | Высокий, когда неизвестно, завершила ли принимающая сторона запрос |
| Аутентификация | Ошибка доступа | После восстановления доступа | Исправить учётные данные и проверить разрешения | Низкий, только если запрос отклонён до побочных эффектов |
| Несовпадение схемы | Ошибка поля или валидации | После исправления контракта или данных | Сверить сборку и сопоставление полей | Зависит от состояния получателя и частичного выполнения |
| Отсутствующий метод | Ошибка метода RPC | После исправления вызова | Сверить развёрнутый код и контракт интеграции | Низкий, если вызов отклонён до побочных эффектов |
| Исходные данные | Ошибка бизнес-валидации | После исправления данных | Исправить запись или правило преобразования | Зависит от того, создала ли первая попытка частичный результат |
| Частичное выполнение | Ошибка задания и проверка получателя | Только после определения безопасной точки продолжения | Сверить созданные объекты и продолжить с безопасного шага | Высокий, когда состояние завершения неизвестно |
Retry, replay и reconciliation — разные операции
Retry
Повтор той же операции после временной ошибки. OCA queue_job поддерживает повторяемые ошибки и настраиваемые интервалы, но безопасность повтора зависит от самого задания и его побочных эффектов. В SPL очередь входила в контур обработки ошибок и повторной обработки операций.
Replay
Повторная обработка сохранённого события или команды после исправления данных или кода. Replay должен фиксировать, что именно запускается повторно, и проверять ранее созданный результат.
Reconciliation
Сверка состояний двух систем независимо от истории отдельных заданий. Она помогает найти пропущенные события, расхождения статусов и частичное выполнение.
Рекомендация автора
Разделяйте диагностику и восстановление: «почему задание упало», «что уже произошло в принимающей системе», «какое действие безопасно сейчас» и «как проверить итог». После исправления отдельно проверяйте состояние принимающей системы.
Защита от повторной обработки
Внешний идентификатор позволяет связать локальную и удалённую записи и перед повтором проверить уже существующий результат. Самого поля недостаточно для полной идемпотентности: нужны правила заполнения, уникальности и обработки частичных ошибок.
В SPL внешние идентификаторы связывали соответствующие записи двух экземпляров Odoo для заказов, закупок, отгрузок, остатков, сообщений и вложений. Это позволяло сопоставлять объекты при синхронизации и повторной обработке, но само по себе не означает формальной идемпотентности всего контура.
Обезличенная последовательность инцидента SPL
- Задание очередиЗапускает синхронизацию остатков через RPC/XML-RPC.
- Marketplace OdooВозвращает ошибку: вызываемый метод отсутствует.
- ДиагностикаОшибка очереди и RPC сопоставляется с фактически развёрнутым кодом.
- ИсправлениеИнтеграционный вызов приведён в соответствие с существующим методом обновления остатков.
Источники
- OCA queue_job 18.0 — повторяемые ошибки, интервалы retry и требование проектировать идемпотентные задания.
- Odoo 18: External API — аутентификация и вызовы методов через XML-RPC.
- Кейс SPL — публичный контекст, объёмы и общий результат оптимизации.
Интеграция регулярно падает?
Разберём границу систем, состояние заданий и безопасный порядок восстановления без обещаний до диагностики.
Обсудить диагностику