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

Не исправляйте только текст шаблона. Проверьте, откуда worker получает order_id, recipient_id и данные для рендера, а также не переиспользуется ли изменяемый объект между заданиями.

Что сделать в первую очередь

  • Приостановите проблемную очередь или конкретный тип уведомлений.
  • Сохраните ID уведомления, заказа и время отправки без распространения содержимого.
  • Проверьте, сколько получателей могло получить неверные данные.
  • Ограничьте доступ к журналам и назначьте ответственного за разбор.

Почему возникает проблема

Смешивание обычно возникает из-за общего состояния, неверной связи получателя с заказом или кэша без tenant/customer key.

  • В задание передаётся объект, который изменяется до выполнения worker.
  • Шаблон читает «последний заказ» вместо заказа по ID.
  • Кэш ключуется только именем шаблона.
  • Пакетная отправка переиспользует переменные предыдущего получателя.
  • Запрос не ограничен customer_id или tenant_id.

Пошаговая диагностика

  • Сопоставьте payload очереди с фактически отрендеренным сообщением.
  • Проверьте SQL-запросы на явную фильтрацию по владельцу.
  • Повторите случай на обезличенной копии с двумя тестовыми клиентами.
  • Проверьте параллельную обработку и статические переменные.
  • Найдите первое и последнее ошибочное сообщение по версии релиза.

Как исправить

Уведомление должно строиться из неизменяемого задания и проверять принадлежность данных непосредственно перед отправкой.

  • Передавайте в очередь только ID сущностей и заново загружайте их в worker.
  • Проверяйте связь order.customer_id с recipient_id.
  • Добавьте tenant_id во все ключи кэша.
  • Создавайте новый контекст шаблона для каждого сообщения.
  • Блокируйте отправку, если проверка владельца не пройдена.

Как проверить результат

  • Параллельные тестовые заказы не смешивают данные.
  • Повтор задания формирует то же корректное сообщение.
  • Негативный тест с чужим recipient_id блокируется.
  • В журнале остаются только безопасные ID и результат проверки.

Как не допустить повторения

  • Добавьте интеграционные тесты изоляции клиентов.
  • Проводите code review запросов без tenant-фильтра.
  • Не храните полный текст уведомлений дольше необходимого.
  • Мониторьте аномалии соответствия получателя и заказа.

Чего не стоит делать

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

Что подготовить для диагностики

  • ID затронутых уведомлений и заказов.
  • Версия приложения и время начала инцидента.
  • Код формирования payload и шаблона.
  • Схема связи клиента, заказа и получателя.

Частые вопросы

Нужно ли менять пароли клиентов?

Не всегда. Сначала определяют, были ли раскрыты данные доступа или только сведения заказа, и действуют по результатам расследования.

Можно ли просто очистить кэш?

Очистка может временно убрать симптом, но без исправления ключа и проверки владельца ошибка вернётся.

Когда стоит обратиться за помощью

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

Итог

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