Конфликты версий Contentful должны безопасно повторяться

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

Такой конфликт — это механизм безопасности. Он не должен становиться тупиком для локализации.

Почему конфликты возникают в здоровых командах

Запрос на перевод может занять время. Пока он генерируется или проверяется, редактор может исправить исходную запись, может быть обновлена другая локаль или автоматизация может изменить метаданные.

К тому моменту, когда локализованное значение готово к отправке, версия записи, зафиксированная ранее, уже устарела.

Это не значит, что кто-то совершил ошибку. Это значит, что несколько частей издательской системы работают одновременно.

Никогда не повторяйте тот же устаревший payload вслепую

Самая простая повторная попытка — это повторить отклоненный запрос. Она не может завершиться успешно, потому что содержит ту же устаревшую версию.

Опасная альтернатива — получить номер последней версии и повторно отправить весь старый payload записи. Это может пройти проверку версии, но при этом перезапишет поля, измененные с момента начала перевода.

Для безопасной повторной попытки нужны актуальное состояние и узкий патч.

Снова прочитать, объединить и обновить

Когда Contentful сообщает о конфликте версий, процесс должен:

1. получить текущую запись из того же space и environment
2. проверить последние поля и версию
3. объединить только утвержденные значения целевой локали из запроса на перевод
4. сохранить несвязанные поля и значения локалей
5. отправить обновление с актуальной версией

Это позволяет повторной попытке соответствовать фактическому намерению пользователя. Запрос на перевод должен был изменить конкретные локализованные поля, а не восстановить старый снимок всей записи.

Решайте, когда не стоит повторять попытку

Автоматическое восстановление после конфликта должно иметь ограничения.

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

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

Ошибка должна оставаться пригодной для действий: указывать запись, затронутую локаль и поля, а также этап, на котором произошло столкновение.

Четко разделяйте ответственность за исходный и целевой контент

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

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

Главное

Конфликты версий — нормальное явление в совместно используемой CMS. Если считать каждый конфликт признаком неудачного перевода, процесс будет казаться хрупким; если игнорировать конфликт, он станет небезопасным.

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