Кросс-постинг: state, идемпотентность и проблемы с кириллицей
Автоматизация кросс-постинга статей в соцсети — задача, которая на первый взгляд кажется простой, но на практике превращается в сложный пайплайн с множеством точек отказа. В этой статье разберем, как state, идемпотентность и проблемы с кодировкой влияют на надежность масс-постинга, и как выстроить рабочий процесс без сюрпризов.
Архитектура пайплайна: разделение на этапы
Ключевая идея — разделить процесс на независимые этапы: source → content package → media resolution → transport → verification → report. Это позволяет локализовать ошибки и формализовать ответственность каждого этапа.
Пакет, транспорт и QC
Пакет отвечает за материалы, транспорт — за доставку, QC — за доказательства выполнения. Такое разделение помогает избежать хаоса, когда агент «все делает сам» и невозможно понять, где именно произошла ошибка.
Проблема с Telegram: таймауты и дубли
Первый инцидент: CLI вернул gateway timeout after 10000ms, хотя пост уже был опубликован. Повторная отправка привела к дублю. Вывод: неуспешный транспортный ответ не является основанием для повторной операции с побочным эффектом. Сначала нужно проверить факт публикации.
Формат сообщения: Markdown vs HTML
Markdown-ссылка визуально сливалась с текстом. Решение — зафиксировать формат сообщения как набор проверяемых условий: короткий анонс, HTML-анкор, разделение на абзацы.
Браузер как fallback: VK, OK и другие
Браузерные сценарии (noVNC) показали нестабильность: антибот-проверки VK, проблемы с загрузкой изображений, потеря карточки предпросмотра в OK. Браузер оставили только как аварийный путь, а основной транспорт — API сервисов отложенного постинга.
API-ответы: не гарантия успеха
HTTP 201 и scheduled не доказывают, что публикация будет корректной. Для каждой площадки нужно проверяемое конечное состояние: идентификатор поста, статус. Иначе запуск нельзя считать успешным.
Изображения: resolver и правила валидации
Проблемы: WebP не везде поддерживается, Google Drive ломает preview, HEAD-запросы обманчивы. Решение — отдельный image resolver с правилами: публичный URL, подходящий формат, размер в лимитах, проверка MIME по реальной загрузке.
Кириллица и U+FFFD: битые символы
В Google Doc попали символы замены Unicode (U+FFFD), означающие потерю данных. Исправить это автоматически невозможно. Поэтому введена байтовая проверка (EF BF BD) и hard gate: если обнаружена порча кодировки, транспорт не запускается.
Рерайты для Дзен и Spark: источник контента
JSON из API оказался плохим источником: попадали CTA, баннеры. Решение — использовать полный публичный HTML с последующей очисткой от нерелевантных блоков. Проверяется структура, объем, отсутствие CTA.
Ограничение области ответственности: одна статья за запуск
Обработка нескольких статей за раз приводит к размножению ошибок. В навыке закреплено ограничение: за один автоматический запуск — только одна свежая неопубликованная статья.
Финальный отчет: рендеринг из состояния
Отчет должен строиться из фактов, а не из памяти модели. Храните state запуска: URL статьи, статусы пакета, медиа, каждого канала, блокеры. Это позволяет избежать ложных утверждений.
Стоп-факторы: превращение ошибок в правила
Каждая ошибка стала стоп-фактором: фиксированный формат caption, проверка факта публикации, проверка карточки перед удалением URL, правила по MIME, байтовая проверка, очистка HTML, проверка состояния каналов. Это сделало процесс надежным.
Рабочая процедура
- Выбрать одну новую статью.
- Получить HTML и очистить от нерелевантного.
- Собрать пакет: анонс, два рерайта.
- Проверить структуру, объем, ссылки.
- Прогнать encoding QC.
- Разрешить и проверить медиа.
- Сформировать Google Doc.
- Опубликовать в Telegram напрямую.
- Запланировать остальные каналы через LiveDune.
- Проверить состояние каждой площадки.
- Завершить с ошибкой, если состояние не доказано.
Часто задаваемые вопросы
Как избежать дублей при таймаутах?
Проверяйте факт публикации перед повторной отправкой. Если пост уже опубликован, не повторяйте операцию.
Почему WebP не подходит для всех площадок?
Некоторые соцсети не поддерживают WebP или имеют ограничения по размеру. Используйте конвертацию в PNG/JPEG с проверкой размера.
Как проверить, что публикация реально запланирована?
Используйте API для получения идентификатора поста и статуса. Только наличие подтвержденного состояния считается успехом.
Заключение
Кросс-постинг — это не просто действие, а система с множеством точек отказа. Внедрение стоп-факторов, проверок состояния и ограничений превращает хаос в управляемый процесс. Начните с малого: разделите пайплайн, добавьте QC и убедитесь, что каждая ошибка становится правилом.
