Когда публикатор не знает, куда публиковать: миграция за 40 часов

40 часов миграции: спасаем социальный паблишер от самого себя

Задача стояла простая, но коварная: почему заметки не публикуются в потоки? В project-social-publisher выписали план на 40 часов работы, и я стал разбираться в корне проблемы.

Первым делом я посмотрел на архитектуру публикации. Оказалось, что система работала с заметками как с самостоятельными сущностями, не привязывая их к контексту конкретного проекта. Когда заметка попадала в API, алгоритм не знал, в какой поток её толкать, и просто зависал на шаге отправки. Это была классическая проблема: достаточно информации для создания заметки, но недостаточно для её таргетирования.

Решение пришло в три этапа. Сначала я добавил поле projectId к заметке — теперь каждая публикация могла быть привязана к конкретному проекту. Вторая проблема была тонкая: хэштеги. Система генерировала какие-то общие #разработка, #код, но потокам нужны были специфичные для проекта метки — #bot-social-publisher, #автоматизация-контента. Пришлось переделать логику генерации хэштегов, добавив правила по типам проектов и их особенностям.

Третьим этапом была доработка самого workflow публикации. В claude_code branch я переписал обработчик отправки в потоки: теперь перед публикацией система проверяет наличие projectId, валидирует хэштеги, специфичные для проекта, и только потом отправляет. Оказалось, что раньше публикация падала молча — логирование просто не было настроено. Добавил детальные логи на каждом шаге, и сразу стало видно, где система буксует.

Интересный момент: когда ты работаешь с системой публикации в социальные сети, нужно помнить о rate-limiting. Каждый сервис (Telegram, Twitter, Reddit — если они в проекте) имеет свои лимиты на количество запросов в секунду. Если ты просто отправляешь заметки в цикле без очереди, система будет заблокирована в течение часа. Поэтому я внедрил простую очередь на базе setTimeout с адаптивной задержкой — система автоматически замедляется, если видит, что сервис отвечает с ошибками 429 (Too Many Requests).

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

Главный вывод: иногда проблема публикации — это не одна большая фишка, а несколько маленьких пробелов в архитектуре. Когда система не знает контекст, она не может принять правильное решение. Вот и весь секрет.

Rate limiting чинит жизнь. Но если ты забудешь про очередь — проблемы чинить нельзя. 😄