Кросс-постинг: стан, ідемпотентність і проблеми з кирилицею
Автоматизація кросс-постингу статей у соцмережі — завдання, яке на перший погляд здається простим, але на практиці перетворюється на складний пайплайн із безліччю точок відмови. У цій статті розберемо, як стан, ідемпотентність і проблеми з кодуванням впливають на надійність мас-постингу, і як вибудувати робочий процес без сюрпризів.
Архітектура пайплайну: розділення на етапи
Ключова ідея — розділити процес на незалежні етапи: 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.
Обмеження області відповідальності: одна стаття за запуск
Обробка кількох статей за раз призводить до розмноження помилок. У навичці закріплено обмеження: за один автоматичний запуск — лише одна свіжа неопублікована стаття.
Фінальний звіт: рендеринг зі стану
Звіт має будуватися з фактів, а не з пам’яті моделі. Зберігайте стан запуску: URL статті, статуси пакета, медіа, кожного каналу, блокувальники. Це дозволяє уникнути хибних тверджень.
Стоп-фактори: перетворення помилок на правила
Кожна помилка стала стоп-фактором: фіксований формат caption, перевірка факту публікації, перевірка картки перед видаленням URL, правила щодо MIME, байтова перевірка, очищення HTML, перевірка стану каналів. Це зробило процес надійним.
Робоча процедура
- Вибрати одну нову статтю.
- Отримати HTML і очистити від нерелевантного.
- Зібрати пакет: анонс, два рерайти.
- Перевірити структуру, обсяг, посилання.
- Прогнати encoding QC.
- Розв’язати та перевірити медіа.
- Сформувати Google Doc.
- Опублікувати в Telegram напряму.
- Запланувати інші канали через LiveDune.
- Перевірити стан кожної платформи.
- Завершити з помилкою, якщо стан не доведено.
Часті запитання
Як уникнути дублів при таймаутах?
Перевіряйте факт публікації перед повторною відправкою. Якщо пост уже опубліковано, не повторюйте операцію.
Чому WebP не підходить для всіх платформ?
Деякі соцмережі не підтримують WebP або мають обмеження за розміром. Використовуйте конвертацію в PNG/JPEG із перевіркою розміру.
Як перевірити, що публікація реально запланована?
Використовуйте API для отримання ідентифікатора поста та статусу. Лише наявність підтвердженого стану вважається успіхом.
Висновок
Кросс-постинг — це не просто дія, а система з безліччю точок відмови. Впровадження стоп-факторів, перевірок стану та обмежень перетворює хаос на керований процес. Почніть з малого: розділіть пайплайн, додайте QC і переконайтеся, що кожна помилка стає правилом.
