Отмена отправки в LINE: как не восстановить удалённое сообщение во входящих

Когда пользователь LINE отменяет отправку сообщения, уберите его содержимое из интерфейса поддержки и прекратите использовать в последующих процессах. Официальное руководство LINE рекомендует отменить отображение и удалить сохранённое содержимое. При интеграции через UnifyPort обрабатывайте message.deleted: надёжно сохраняйте маркер удаления и запускайте очистку с повторными попытками. Удалить только строку во входящих недостаточно: позднее событие может создать её заново, а поиск или контекст ИИ — сохранить копию.

Главное

• Получить уведомление об отзыве сообщения — не то же самое, что запросить отзыв через API.
• Устраняйте дубли событий по ID события, а целевое сообщение находите по data.message.id в области нужного аккаунта.
• Минимальный маркер удаления должен блокировать восстановление из запоздалых сообщений и правок.
• Подтверждение webhook не означает, что все копии уже удалены. Состояние очистки отслеживайте отдельно.

Что LINE рекомендует делать с сохранённым содержимым

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

Это официальная рекомендация. Маркер удаления, транзакционный outbox и тесты ниже — предлагаемый дизайн приложения, а не функция LINE и не юридическое заключение о сроках хранения.

Редактирование заменяет содержимое, отзыв прекращает его использование. Если вы также обрабатываете правки, сохраните схему обработки LINE message.updated, но проверяйте маркер перед записью нового текста. История редакций не должна оставаться скрытой копией, доступной оператору или поисковому процессу.

Не смешивайте контракты событий

У приёмника официального LINE Messaging API и приёмника UnifyPort разные форматы данных и проверки подлинности. Не передавайте исходное тело LINE обработчику нормализованных событий без отдельного адаптера.

Справочник стандартных событий UnifyPort определяет message.deleted как удаление или отзыв сообщения. В объекте message гарантируется только data.message.id; текст и медиа исключаются. Матрица событий провайдеров указывает такое сопоставление для LINE, Telegram и WhatsApp, но не гарантирует, что каждый аккаунт или развёртывание будет выдавать все сопоставленные события.

Ниже — иллюстрация с документированными полями и вымышленными идентификаторами, а не перехваченная доставка:

{
  "id": "evt_6d91a2c8",
  "type": "message.deleted",
  "provider": "line",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-09-23T08:15:00Z",
  "data": {
    "conversation": { "id": "c8f2a4d91e", "type": "group" },
    "message": { "id": "551842037194" },
    "event": { "kind": "message_deleted" }
  }
}

Верхний id обозначает событие; data.message.id — удалённое сообщение. Не используйте первый для поиска сообщения и не трактуйте отсутствие текста как редактирование в пустую строку.

Сначала зафиксируйте запрет на восстановление

Добавьте message.deleted в subscribed_events вместе с нужными событиями получения и редактирования. Включите signing_secret. По контракту доставки проверяйте HMAC-SHA256 от временной метки, точки и исходных байтов тела запроса, а также допустимую давность временной метки. В руководстве по защите от повторного воспроизведения объясняется, почему проверка подписи и надёжная дедупликация решают разные задачи.

После проверки подлинности и структуры данных:

1. Найдите цель в правильном workspace, провайдере и аккаунте обмена сообщениями. Используйте ID беседы и сообщения, когда они доступны. Если контекста беседы нет, допускайте только уже существующее однозначное сопоставление внутри аккаунта. Не угадывайте между чатами; неразрешённые цели изолируйте для проверки.
2. В одной транзакции сохраните отметку дедупликации, создайте или сохраните минимальный маркер удаления, уберите рабочее содержимое и поставьте задачи очистки. Сериализуйте этот переход с записью получения и правок для той же цели.
3. Возвращайте 2xx только после надёжного принятия. Очистку внешних систем повторяет отдельный worker.
4. Каждый обработчик получения и редактирования должен проверять маркер. Запоздалое событие не должно восстанавливать текст или запускать новую задачу ИИ.

Это предлагаемые состояния приложения, не поля API:

Сохранённое состояние	Новое событие	Действие
Оригинала нет	Удаление	Сохранить маркер без содержимого, не ждать оригинал
Содержимое доступно	Удаление	Скрыть содержимое и поставить очистку
Есть маркер удаления	Получение или правка	Не восстанавливать содержимое
Есть маркер удаления	Повторное удаление	Сохранить состояние, продолжить незавершённую очистку

Не полагайтесь только на порядок прихода или принцип «побеждает последняя временная метка». UnifyPort не гарантирует порядок доставки. Маркер — осознанное правило приложения: удаление остаётся действующим для этой идентичности сообщения.

Проследите за копиями, а не только строкой во входящих

Храните локальное соответствие исходного сообщения и производных объектов. Следующая таблица — перечень объектов для проверки, а не обещание автоматической очистки со стороны UnifyPort:

Копия или задача	Рекомендуемое действие
Текст и превью во входящих	Удалить содержимое, инвалидировать кеш
Скачанные вложения	Удалить управляемые копии и миниатюры
Поисковый и векторный индексы	Удалить записи, блокировать извлечение до завершения
Контекст ИИ, сводки, ожидающие ответы	Исключить источник, инвалидировать сводки, отменить или проверить зависимые задачи
Пересылки в CRM и командные чаты	Удалить или скрыть содержимое, если возможно; учесть оставшиеся копии
Сырые журналы, dead-letter очереди, резервные копии	Применить правила доступа и хранения, не допустить восстановления в рабочие представления

Worker должен повторно проверять удаление перед извлечением данных, публикацией сгенерированного текста и перестроением индекса. По возможности согласуйте публикацию с тем же механизмом блокировки на уровне сообщения. Действие, уже переданное внешней системе, может оказаться необратимым: зафиксируйте эту границу вместо обещания полного стирания.

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

Приёмочные тесты и ограничения

Используйте контролируемые тестовые сообщения, не данные клиентов. Это предложенные проверки, а не заявленные результаты:

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

UnifyPort предоставляет неофициальный интерфейс и нормализованный поток событий, но не удаляет данные из ваших CRM и ИИ автоматически. У него нет REST API чтения истории сообщений и гарантированного воспроизведения пропущенных событий. Отсутствие события удаления не доказывает, что отзыва не было. Если продукту нужен нативный контракт LINE Official Account, предпочтителен официальный путь.

FAQ

message.deleted запрашивает отзыв чужого сообщения?

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

Можно восстановить оригинальный текст из события удаления?

Нет. Документированный объект гарантирует ID цели, а не удалённые текст или медиа. Не превращайте обработку отзыва в функцию восстановления содержимого.

HTTP 200 означает, что все копии удалены?

Нет. Это подтверждение доставки. Завершение очистки и ошибки приложение учитывает отдельно.

Следующий шаг и источники

Проверьте матрицу webhook-событий и добавьте тест «удаление раньше оригинала», прежде чем включать обработку ИИ.

Источники проверены 2026-09-23:

• LINE: получение сообщений и обработка unsend
• LINE: справочник Messaging API
• UnifyPort: стандартные события
• UnifyPort: доставка и проверка подписи