BorisovAI
Все публикации
ИсправлениеopenclawGit коммит

Когда группа видна, а отправитель — нет: история одного бага

Когда группа видна, а отправитель — нет: история одного бага

Когда group chat показывает группу, но скрывает отправителя

Проект OpenClaw — это не новый стартап, это сложная экосистема для работы с разными мессенджерами. И вот в BlueBubbles, интеграции для синхронизации Apple Messages, обнаружилась тонкая проблема: когда кто-то писал в групповой чат, группа отображалась как группа, но вот кто именно написал сообщение — оставалось загадкой. Представь: на экране видишь «[BlueBubbles] Сообщение пришло в “Друзья на даче”», а автора — хоть ты тресни.

Задача была чёткая: сделать, чтобы в групповых чатах группа показывалась нормально, но при этом было видно, кто именно написал. Звучит просто, но в голове разработчика крутилось одно: как это реализовано в других каналах? Потому что вбивать велосипед — верный путь к техдолгу.

Первым делом достали функцию formatInboundEnvelope — она уже использовалась в iMessage и Signal. Оказалось, там логика уже готовая: группе выделяется свой вид в заголовке (envelope header), а имя отправителя добавляется в тело сообщения. Скопировать этот паттерн в BlueBubbles значило привести всё в соответствие с остальной системой.

Но тут вылезла вторая проблема: после форматирования сообщения нужно его ещё и обработать правильно. Включили finalizeInboundContext — функцию, которая нормализует поля, выставляет правильный ChatType, подставляет ConversationLabel и выравнивает MediaType. То есть применили тот же подход, что в iMessage и Signal. BodyForAgent при этом переключили на сырой текст (rawBody) вместо обёрнутого в конверт — иначе агент будет работать с [BlueBubbles ...] текст сообщения, а не с чистым текстом.

И вот неожиданность: нужно было выровнять fromLabel с функцией formatInboundFromLabel. Суть в том, что для групп нужно писать «GroupName id:peerId», для личных сообщений — «Name id:senderId» (если имя отличается от ID). Мелкая, казалось бы, деталь, но она делает систему консистентной: везде одинаковый формат.

Интересный факт: когда разные каналы используют разные форматы одних и тех же данных, это тихий убийца debugging’а. Тестировщик смотрит на iMessage, видит одно, смотрит на BlueBubbles — видит другое. Казалось бы, одна функция, один формат, но нет — каждый канал решил, что сам знает лучше. Поэтому когда разработчик вспомнил о единообразии, это был момент, когда система стала ровнее.

Результат: BlueBubbles теперь работает как остальные каналы. Групповые чаты показываются группой, отправители видны, ConversationLabel наконец начинает возвращать имя группы вместо undefined. И главное — это не кастомный костыль, а применение существующего паттерна из iMessage и Signal. Система стала более предсказуемой.

Теперь, когда приходит сообщение в групповой чат BlueBubbles, всё отображается логично: видна группа, видно, кто пишет, агент получает чистый текст для обработки. Ничего особенного, просто хорошая инженерия.

Разработчик на собеседовании: «Я умею выравнивать форматы данных между каналами». Интервьюер: «А конкретно?» Разработчик: «Ну, BeautifulSoup, regex и… молитвы к богу синхронизации». 😄

Метаданные

Branch:
main
Dev Joke
Разработчик: «Я знаю gRPC». HR: «На каком уровне?». Разработчик: «На уровне Stack Overflow».

Оцените материал

0/1000