Разрешение конфликтов

Когда возникают конфликты

Конфликт данных возникает, когда одна и та же запись изменяется из разных источников до того, как изменения были синхронизированы. Типичные сценарии:

Два устройства оффлайн

Два члена команды работают оффлайн на разных устройствах и изменяют одну запись. Например:

• Оператор на входе отмечает check-in участника и добавляет комментарий «VIP»
• Менеджер на другом устройстве отмечает тот же check-in и добавляет комментарий «Доп. место»
• При восстановлении связи оба изменения отправляются на сервер

Оффлайн + онлайн

Один член команды работает оффлайн, другой -- онлайн:

• Менеджер за компьютером (онлайн) изменяет статус регистрации
• Оператор на площадке (оффлайн) изменяет тот же статус
• При синхронизации оффлайн-изменение конфликтует с уже применённым онлайн-изменением

Когда конфликты маловероятны

На практике конфликты возникают редко, потому что:

• Разные члены команды обычно работают с разными участниками
• Check-in -- однонаправленная операция (отметка прибытия), конфликт check-in возможен только при двойном сканировании
• Платежные операции защищены idempotency-key

Стратегия: last-writer-wins (Free, Pro)

На тарифах Free и Pro используется автоматическая стратегия last-writer-wins (побеждает последний):

Как это работает

1. При синхронизации сервер сравнивает метки времени clientTs конфликтующих изменений.
2. Изменение с более поздней меткой времени автоматически сохраняется.
3. Изменение с более ранней меткой перезаписывается.
4. Оба изменения фиксируются в audit log (даже перезаписанное).

Пример

Преимущества и ограничения

Преимущества:

• Полностью автоматический -- не требует вмешательства пользователя
• Не прерывает рабочий процесс
• Подходит для большинства сценариев (check-in, простые статусы)

Ограничения:

• Более раннее изменение теряется без уведомления
• Нет возможности объединить два изменения
• Для критически важных данных может привести к потере информации

Стратегия: optimistic locking + merge UI (Business, Enterprise)

На тарифах Business и Enterprise доступна интерактивная стратегия разрешения конфликтов с визуальным интерфейсом.

Как это работает

1. При синхронизации сервер обнаруживает конфликт (запись была изменена после последнего известного клиенту состояния).
2. Вместо автоматической перезаписи сервер возвращает обе версии.
3. Пользователю показывается merge UI -- интерфейс сравнения версий.
4. Пользователь выбирает, какую версию сохранить, или объединяет изменения вручную.

Merge UI

Интерфейс разрешения конфликтов показывает:

• Левая колонка: ваша версия (локальное изменение)

  • Автор изменения
  • Время изменения
  • Измененные поля с их значениями

• Правая колонка: серверная версия (чужое изменение)

  • Автор изменения
  • Время изменения
  • Измененные поля с их значениями

• Действия:

  • «Оставить мою версию» -- ваше изменение перезаписывает серверное
  • «Принять серверную» -- серверная версия сохраняется, ваше изменение отменяется
  • «Объединить» -- вы вручную выбираете значение для каждого поля

Пример

Вы можете принять check-in из обеих версий (совпадают), взять свой комментарий и серверный статус.

Optimistic locking

Под капотом используется optimistic locking:

• Каждая запись имеет версию (version counter)
• При отправке изменения клиент указывает, на какой версии оно основано
• Если версия на сервере изменилась (кто-то другой обновил запись), сервер возвращает конфликт
• Клиент показывает merge UI

Уведомления о конфликтах

При обнаружении конфликта:

Free / Pro: toast-уведомление «Конфликт данных разрешен автоматически» (информационное, без действий).

Business / Enterprise: toast-уведомление «Обнаружен конфликт. Требуется ваше решение» с кнопкой для перехода в merge UI. Конфликт блокирует синхронизацию остальных изменений до его разрешения.

Рекомендации

• Распределяйте зоны ответственности. Назначайте членам команды разные группы участников или зоны check-in, чтобы минимизировать конфликты.
• Синхронизируйтесь чаще. Короткие периоды оффлайн-работы снижают вероятность конфликтов.
• Используйте merge UI для критичных данных. Если ваша команда активно работает с одними и теми же записями, рассмотрите переход на Business для доступа к интерактивному разрешению конфликтов.