Миграция collaboration 2.4 → 2.5#

Миграция 20261025010000_incident_responders_stakeholders меняет владельца responders и stakeholders с AlertGroup на Incident. Поддерживаются SQLite и PostgreSQL. Другие СУБД отклоняются до замены таблиц: нужны транзакционный DDL и частичные индексы.

Правила переноса#

различным Incident. Несколько связей с одним и тем же Incident допустимы.

Новый Incident не создаётся. Сохранение этих записей в новой схеме не требуется.

PostgreSQL sequences переводятся за последний сохранённый ID.

остаётся запись с минимальным legacy ID. Другие статусы сохраняются отдельно. Legacy-запросам назначается роль responder.

из accepted_by, исходный адресат сохраняется. Неизвестный пользователь не выдумывается.

email; внешний email нормализуется по пробелам и регистру. Разные роли остаются разными записями; сохраняется минимальный ID.

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

исходным AlertGroup, ID итоговой записи и операционной историей. Текст ошибок доставки и адреса получателей не копируются в эти события.

• У AlertGroup должны быть активные связи (removed_at IS NULL) ровно с одним
• Записи без такой связи и записи с несколькими различными Incident пропускаются.
• У сохраняемых записей остаются ID, авторы действий, статусы, текст и время.
• Принятые responder-запросы одного Incident, пользователя и роли объединяются:
• Для принятого запроса команды/ротации/политики конкретный пользователь берётся
• Stakeholders объединяются по Incident, адресату и роли. User ID приоритетнее
• Флаги активных дублей объединяются через OR. Неактивный дубль не включает
• Объединение отражается событием collaboration_record_merged с legacy ID,
• Технические комментарии AlertGroup не переносятся и не переписываются.

Порядок обновления#

восстановление в отдельную БД. Для SQLite не копируйте только основной файл, пока возможна запись в WAL.

через INCIDENTRELAY_CONFIG_FILE перед выполнением команд.

Сохраните JSON-отчёты preflight и reconciliation.

• Остановите web, intake workers, scheduler и остальные процессы записи в БД.
• Сделайте полную резервную копию штатным механизмом СУБД и проверьте её
• Сначала отрепетируйте обновление на отдельной копии. Явно укажите её конфигурацию
• Выполните python manage.py migrate, затем python -m app.check_schema.
• Для responders и stakeholders проверьте:

``text legacy = migrated + merged + unmapped + ambiguous eligible = migrated + merged ``

legacy — исходные записи; eligible — однозначно сопоставленные; migrated — итоговые сохранённые записи; merged — объединённые дубли; unmapped и ambiguous — намеренно пропущенные. В preflight migrated/merged ещё равны нулю.

новых записей после сохранённых ID и повторный запуск без новых миграций.

конфигурацией. Запускайте процессы только после проверки результата.

• Проверьте участников, подписчиков, исходные технические комментарии, создание
• После успешной репетиции повторите процедуру с новой production-копией и нужной

Ошибка и откат#

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

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

Runner не повторяет уже записанные как выполненные миграции. Если ранняя сборка 2.5 уже применила прежний вариант этой миграции, обновление файла её не исправит: репетируйте исправленный переход после восстановления проверенной копии 2.4.

После успешного commit откат требует полной pre-upgrade копии БД и соответствующей версии приложения при остановленных процессах записи. Пропущенные legacy-записи из мигрированной БД восстановить нельзя.