Три канала — два Telegram-бота и VK-сообщество. Около 8000 человек суммарно. Скрипты написаны, база залита, dry-run чистый. Нажимаем.
Ссылка в никуда: трекинговый редирект из Фазы 2 в тексте Фазы 1
Агент гонит финальную проверку перед messages.send — и стопорится на VK-сообщении. В тексте трекинговая ссылка go.kazanflowerschool.ru. Редирект для аналитики: человек жмёт, попадает на поддомен, тот считает клик и кидает дальше в Telegram.
Только этого редиректа не существует. Он был в плане на Фазу 2. Поддомен не подняли. Ссылка вела бы в пустоту — 3375 человек в VK кликнули бы по битому домену.
Агент поймал это до отправки. Сравнил текст со списком задеплоенного, увидел расхождение, остановился. Убрал трекер, поставил прямую t.me/.... Без редиректа теряем аналитику переходов — но сейчас Фаза 1, считаем по факту подписки в боте.
Лимиты VK API: почему голый fetch даёт 20 минут на 3375 человек
Смотрим в код отправки: голый fetch к VK API, пауза 350 миллисекунд между вызовами. Считаем: 3375 × 350ms = около 20 минут только на VK, если ни одна отправка не подвиснет.
«Смотри через Exa — возможно ли параллельно».
И тут момент, который стоит зафиксировать честно.
Агент только что читал наш же код. Там голый fetch без SDK — прямо в том файле, который он открыл секунду назад. И всё равно пошёл выяснять: «а какая у нас библиотека для VK?». Своё текущее решение не знал. Признал вслух — «не вижу в проекте клиента, иду смотреть, что есть» — и пошёл ресёрчить то, что лежало под носом.
Объяснение простое: код писался в разных сессиях разными агентами. «Что у нас уже написано» — нигде не задокументировано. Каждый новый агент стартует с нуля.
vk-io вместо fetch: параллельные вызовы и retry на media upload
Ресёрч через официальную документацию дал ответ: vk-io — TypeScript-клиент с execute для пакетной отправки, параллельными вызовами и встроенным rate limit контролем. Переписали отправщик на него. Двадцать минут схлопнулись в считанные.
Новый путь через vk-io тут же упал на загрузке фото. Потом упал ещё раз, на той же стадии — photos.getMessagesUploadServer отдавал ошибку без внятной причины. Не сеть, не права — VK просто иногда тупит на media upload. Лечится повтором.
Поставили auto-retry ×5, таймаут 60 секунд на попытку. Первая — мимо, вторая — мимо, третья прошла. Картинка ушла. Финальный typecheck, прогон на тестовые аккаунты — чисто. Боевая отправка.
Итог: 6029 доставлено, стек grammY + vk-io на TypeScript
| Канал | Доставлено | Отсеяно |
|---|---|---|
| VK | 3 206 | ~169 |
| Telegram-бот 1 | 1 649 | — |
| Telegram-бот 2 | 1 174 | — |
| Итого | 6 029 | 2 255 |
VK 3206, плюс два бота на grammY — 1649 и 1174. Итого 6029 доставлено за один день на Bun + TypeScript. 2255 — мёртвые и заблокированные: удалили бота, закрыли личку, аккаунт удалён. Отсеялись сами, по факту ошибки доставки.
Пока разбирали кодовую базу под VK, наткнулись на workers/telegram/src/promo/quiz.ts — квиз-бот, закоммиченный в мае. State-machine на grammY, таблицы в базе, уведомление о новом лиде, сегментация по горячести. Полностью рабочий. Никем не задокументирован. Лежал мёртвым грузом — никто не помнил. Добавили в карту проекта.
Если собираете рассылку по Telegram и VK — пишите: @afonin900.