Ошибки в BAS: почему бот падает и как его отладить

Бот в BAS почти никогда не ломается «сам по себе». Он ломается там, где реальность разошлась с ожиданием: страница пришла медленнее, вёрстка изменилась, прокси лёг. Отладка - это в первую очередь умение быстро узнать, в каком именно месте это произошло.

Элемент не найден

Самая частая ошибка - и самая часто неправильно понятая. Причин ровно три, и лечатся они по-разному.

Элемента ещё нет. Скрипт дошёл до проверки раньше, чем страница дорисовалась. Так бывает у всего, что подгружается динамически. Лечение - не увеличение паузы, а ожидание самого элемента: фиксированная пауза либо тратит время впустую, либо однажды окажется короткой.

Селектор хрупкий. Он привязан к классу вида css-1x7f9a, сгенерированному сборщиком, - такой класс меняется при каждом деплое сайта. Держитесь за то, что осмысленно: текст, атрибуты, структуру. Подробнее - в статье про устойчивые селекторы.

Элемент в другом контексте. Он внутри iframe или в другой вкладке, а бот ищет в текущем документе. Формально элемент на экране есть - для скрипта его нет.

Браузер не запускается

Если поток падает сразу на старте, порядок проверки такой:

1. Память. Самая частая причина - потоков больше, чем машина тянет. Браузер не стартует, потому что памяти уже нет. Снизьте число потоков и проверьте, ушла ли ошибка.
2. Первый запуск после сборки. Скомпилированному боту нужно докачать окружение, и без интернета он не стартует.
3. Антивирус. Автоматизирующее приложение, качающее компоненты, - типичный кандидат на блокировку.
4. Остатки прошлых запусков. Подвисшие процессы браузера от аварийно завершённых потоков занимают память и мешают новым.

Прокси не отвечает

Ошибки прокси коварны тем, что маскируются под другие. Бот сообщает «страница не загрузилась» или «элемент не найден», хотя настоящая причина - мёртвый адрес.

Признак, по которому это опознаётся: падения привязаны к потоку, а не к шагу. Если поток №4 валится всегда, а остальные идут, дело почти наверняка в его прокси. Отсюда практический вывод - проверять прокси перед работой, а не выяснять их состояние по кривым симптомам в середине сценария.

Скрипт зависает

Зависание отличается от падения: бот не сообщает об ошибке, он просто стоит. Причина всегда одна - ожидание события, которое уже не наступит:

• ждём элемент, который не появится на этой странице;
• ждём завершения загрузки, которая закончилась до начала ожидания;
• ждём код с почты, который не придёт.

Лечение системное: у каждого ожидания должен быть конечный таймаут. Бот, упавший через минуту с внятной ошибкой, несравнимо лучше бота, который сутки держит поток и портит статистику.

Работает в студии, падает в проде

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

Проверка простая: запустите на чистом профиле и на полном числе потоков. Большинство «необъяснимых» расхождений всплывает сразу.

Схема отладки

Отлаживайте не догадками, а следами. Минимальный набор, который окупается на первом же инциденте:

Логируйте шаги, а не факт падения. Строка «ошибка» бесполезна. Строка «поток 4, аккаунт ivan@mail, шаг «вход», элемент кнопки не найден» - почти диагноз. Пишите в файл через модуль инструментов, а не только на экран: экран вы не увидите, когда бот работает у клиента.

Снимайте скриншот при падении. Одна картинка отвечает на вопрос, который иначе стоит часа: там была капча, редирект, баннер согласия или пустая страница. Это самый дешёвый диагностический инструмент в автоматизации.

Сохраняйте HTML на неудачных шагах. Когда селектор перестал находиться, единственный способ понять почему - увидеть разметку, которая была в этот момент.

Считайте отказы по типам. Разделяйте «не нашёл элемент», «прокси умер», «капча» - это разные проблемы с разными решениями. Общая цифра «40% неудач» не говорит ни о чём; статистика по причинам говорит, что чинить.

Повторы вместо падений

Часть ошибок не требует остановки - они временные: сеть моргнула, страница пришла медленнее обычного, прокси задумался. Такие шаги разумно повторять, а не ронять на них весь поток.

Правило разделения простое. Повторять имеет смысл сетевые сбои и таймауты загрузки - то, что при следующей попытке может пройти. Не повторять - неверные учётные данные, отсутствующий аккаунт, исчерпанный лимит: тут повтор только тратит время и приближает бан.

И отдельно: повтор без ограничения - это скрытый бесконечный цикл. Всегда задавайте предел числа попыток.