Если транзакционное письмо содержит данные другого клиента, это критичная ошибка: пользователь получает чужой заказ, имя, адрес, ссылку или персональную информацию. Тут важно быстро остановить повторение и найти точный источник подстановки.
Сначала нужно приостановить проблемный тип письма или ограничить отправку, затем проверить шаблон, очередь, payload и логи конкретной отправки.
Коротко: что делать
- Найти письмо, шаблон и событие, которое его отправило
- Проверить payload конкретной отправки
- Остановить повторную отправку проблемного шаблона
- Проверить кеш шаблона и глобальные переменные
- Оценить, какие данные могли уйти не тем получателям
Основные причины
Такие ошибки часто возникают из-за переиспользования объекта, неправильного join, общей переменной, кеша или batch-обработки.
- Шаблон берет данные из глобального состояния
- Очередь хранит ID клиента, а обработчик подставляет последний загруженный объект
- Неправильный join связывает заказ и получателя
- Batch-рассылка не очищает переменные между письмами
- Кеш шаблона или preview попадает в реальную отправку
Пошаговая диагностика
Диагностику нужно делать по одному конкретному письму: кому ушло, какие данные внутри и какой payload был в очереди.
- Найти message id и запись в логе отправки
- Сравнить получателя, заказ, клиента и payload
- Проверить код генерации шаблона
- Проверить очередь и retry
- Проверить, повторяется ли ошибка на тестовой отправке
Как исправить проблему
Исправление должно гарантировать, что письмо строится из данных конкретного события, а не из случайного состояния приложения.
- Передавать в очередь полный безопасный контекст или проверенные ID
- Исправить запросы связывания клиента, заказа и получателя
- Убрать глобальные переменные и переиспользуемые объекты из шаблонизации
- Добавить тесты на batch-отправку нескольким клиентам
- Добавить аудит отправок и контроль персональных данных
Безопасный план решения
Сначала остановите повторение ошибки, затем разберите affected users, после этого исправляйте код и только потом включайте отправку обратно.
Чего не стоит делать
- Не продолжать отправку, пока причина не понятна
- Не править только текст шаблона, если ошибка в данных
- Не удалять логи до анализа
- Не игнорировать юридические и репутационные риски утечки
Что подготовить перед исправлением
- Пример ошибочного письма
- Message id или время отправки
- Шаблон письма
- Логи очереди и отправщика
FAQ
Это ошибка шаблона или базы?
Может быть и то, и другое. Нужно смотреть payload отправки и код подстановки переменных.
Нужно ли отключать все письма?
Если ошибка только в одном шаблоне, лучше временно отключить его. Но массовый риск нужно оценить быстро.
Как проверить исправление?
Отправить тестовую batch-серию разным пользователям и сверить все персональные поля.
Когда стоит обратиться за помощью
Помощь нужна сразу, если в письме есть персональные данные, адреса, заказы, платежи или ссылки доступа.
Итог
Начните с остановки проблемного шаблона и анализа payload. Если нужно найти причину подстановки чужих данных и безопасно включить письма обратно, можно написать в Telegram @rabotator_support.