Ошибки и отладка chromedp

Реальные сбои браузерных парсеров на Go сводятся к четырём семействам, и в логе они выглядят узнаваемо. Первое — context deadline exceeded: дедлайн истёк, страница не успела загрузиться или сайт медленный. Второе — «no node set» или пустой результат query: селектор не нашёл узел, чаще всего потому, что страница рендерится JavaScript'ом позже, чем код пытается читать. Третье — connection refused: Chrome не поднялся или порт отладки занят, программы вообще не с чем разговаривать. Четвёртое — tab crashed и context canceled без вашей вины: вкладка или весь браузер погибли, обычно от памяти при сотнях вкладок. Четыре семейства — не потому, что chromedp беден на ошибки, а потому, что архитектура проста: процесс Chrome, DevTools-протокол поверх вебсокета, контекст Go — и ломаться может только одно из трёх звеньев. Разбор всегда идёт сверху вниз: сначала текст ошибки, потом звено, потом причина — и только после этого код. Дальше — каждое семейство отдельно, с причиной и лечением, а в конце урока таблица для быстрых разборов.

context deadline exceeded — самый частый гость, и почти всегда это не баг библиотеки, а арифметика из пятнадцатого урока: дедлайн шага меньше реального времени страницы. Медленный сайт, тяжёлая страница, сеть на другом краю страны — действие честно не уложилось в потолок. Классификация проста: перишаговый дедлайн истёк — ретрай с бэкоффом и свежим контекстом часто проходит; дедлайн сгорел на первом Run, который аллоцирует браузер, — погибли все последующие Run, и это уже авария конфигурации, а не сеть. Проверяйте причину через errors.Is(err, context.DeadlineExceeded), а не сравнением строк: обёртки и ретраи наворачивают слои, и только errors.Is видит сквозь них. Отдельный случай — context canceled при живом браузере и вашей невиновности: контекст отменила сама библиотека, потеряв соединение с браузером, — ретрай в мёртвый контекст бессмыслен, нужен новый NewContext от аллокатора. И помните про отсчёт: дедлайн стартует от вызова WithTimeout, а не от начала Run, — минуты между созданием контекста и Run съедаются молча. Отдельно тренируйте привычку записывать затраченное время каждого шага: потолок, выведенный из замеров, лечит таймауты навсегда, а угаданный — воспроизводит их еженедельно.

Второе семейство ловит гонку «код быстрее страницы». Query-механика умеет ждать: по умолчанию стоит условие NodeReady — узлы должны существовать, и хелпер внутри крутит проверку с миллисекундными паузами до готовности или дедлайна. Поэтому Text по селектору, которого нет вообще, будет молча ждать до конца контекста — и вернёт таймаут, а не ошибку селектора. Но между «узлы появились» и «данные дописаны» проходит время, и при перерисовке SPA узел, который вы уже прочитали, заменяется новым: действие получает пустой или протухший набор узлов — в логах это всплывает как «no node set» или пустая строка без ошибки. Evaluate добавляет третью ловушку: он ничего не дожидается сам, и мгновенный Evaluate по ещё не отрисованному DOM вернёт null или пустой массив, хотя страница через полсекунды отрисуется. Лечение одно и то же: WaitVisible на устойчивый якорь контента вместо мгновенных чтений, poll-предикаты из девятого урока для изменчивых данных, повтор после перерисовки. Это ровно механика динамического контента из одиннадцатого урока — здесь она проявляется как ошибка, там — как техника. Диагностика простая: тот же селектор через пару секунд находит узел — значит, дело во времени, а не в разметке.

chromedp отладка начинается с простого шага: выключите невидимость. В DefaultExecAllocator из второго урока прописан headless-режим — флаг Headless в списке опций, — и выключается он добавлением своей опции Flag("headless", false) к срезу аллокатора: браузер запустится окном, и вы увидите всё своими глазами — где кликает программа, что рисует сайт, не вылезла ли капча. Это самый быстрый отладчик из существующих и его недооценивают: пятнадцать секунд наблюдения отвечают на вопросы, на которые лог не ответит и за вечер. Второй инструмент — FullScreenshot(res, quality): полное изображение страницы целиком, включая то, что за пределами вьюпорта, — «что видит браузер» в отличие от того, что видит curl: скрипты исполнены, стиль применён, картинка честная. Третий — дамп HTML после падения из примера выше, открываемый офлайн. У тройки есть общее правило: собирать их надо в момент сбоя, а не после — перезапуск уже изменит состояние сайта, капча переедет, и разбор станет гаданием. Окно с браузером на рабочем столе выглядит несерьёзно рядом с профайлером, но за пятнадцать секунд наблюдения оно отвечает на вопросы, на которые профайлер не ответит никогда.

Tab crashed — диагноз памяти: вкладка или браузер погибли, когда одной из сотен вкладок девятнадцатого урока не хватило памяти. Chrome падает по-разному — иногда гаснет вкладка, иногда весь процесс, — но для программы это выглядит одинаково: действия возвращают context canceled, а новый Run в том же контексте молчит. Симптом надёжнее причины: обход с пулом из девятнадцатого урока начал ронять задания через сорок минут — считайте это сигналом OOM, пока не доказано иное. Лечение — снижение потребления: меньше вкладок на браузер, меньше одновременно живых контекстов, обязательно defer cancel() на каждую вкладку — забытый cancel живёт до конца программы и держит вкладку. Для поиска утечек вкладок подходит стандартный арсенал Go: импорт net/http/pprof поднимает профиль — счётчик горутин, растущий от задания к заданию, почти всегда означает контексты без отмены, а heap-профиль показывает, что именно держит память. Снимайте профили на живом обходе, а не после падения: утечка видна в динамике, где две кривые расходятся. И держите лимит вкладок как константу рядом с пулом: растить параллелизм дешевле, чем лечить OOM на проде.