bug: дневной сбор падает DownloadTimeoutError на первом скачивании (регрессия после 45512d4, не исправлено #28)

[axisrow]

Что происходит

Дневной сбор падает DownloadTimeoutError на первом же скачивании и не доходит до dynamics. Воспроизводится на двух версиях подряд, включая свежий фикс #28.

Воспроизведение

Дата: 2026-08-21. CDP http://127.0.0.1:9223, авторизованный профиль. Капчи, редиректа на passport и разлогина не было.

wordstat collect "новогодние подарки" "купить телефон" "курсы английского языка" \
  --granularity daily \
  --date-from 2026-06-23 --date-to 2026-08-20 \
  --cdp-url http://127.0.0.1:9223 \
  --region "Россия" --timeout 90

Результат: Собрано 0 из 3. Все три фразы независимо — DownloadTimeoutError на первом CSV.

Манифест (одинаков у всех трёх)

"exports": [],
"granularity": "daily",
"requested_period": {"from": "2026-06-23", "to": "2026-08-20"},
"actual_period": null,
"missing_views": ["top_popular", "top_related", "dynamics", "regions"],
"empty_views": [],
"status": "incomplete"

created_at и updated_at совпадают до микросекунды — прогон умирает на первом скачивании, не записав ни одного экспорта.

Что уже исключено

• Не версия. Падает и на d3e6ed2 (fix: stop failing closed on always-empty top views, close orphaned tabs (#22, #9) #25), и на fc0e9a1 (fix: contain downloads to their own directory, keep partial results (#27) #28). Фикс fix: contain downloads to their own directory, keep partial results (#27) #28 адресовал «сбежавшие» пути загрузок и TCC на macOS — судя по симптому, это другой дефект: файл не «уходит мимо каталога», он не появляется вообще.
• Не конкуренция за браузер. Воспроизведено в одиночном прогоне при свободном CDP (load average ~5, 4 target'а), а не только при параллельных сессиях.
• Не таймаут как таковой. Пробовали --timeout 45 (default), 90 и 120 — симптом идентичен.
• Не авторизация. Страница Wordstat открыта в залогиненном состоянии, признаков капчи или редиректа нет.
• Не пустые топы. top_popular/top_related пусты у платформы всегда (top_popular/top_related возвращают 0 строк данных при --keep-raw, хотя интерфейс показывает данные #11, После #19 ни один полный прогон не завершается: fail-closed срабатывает на всегда-пустом top_popular #22), но здесь они в missing_views, а не в empty_views — то есть до экспорта дело не дошло, это не эффект пустоты.

Важное наблюдение

Тот же сбор с теми же параметрами проходил на версии 45512d402cd75e8c30703c2bfdb86cb1a7a059e5: три фразы, по 58 строк дневной динамики, окно 23.06.2026–19.08.2026, файлы корректны (UTF-8 BOM, CR-only, ;). То есть между 45512d4 и d3e6ed2 сбор дневной динамики сломался и на fc0e9a1 остаётся сломанным.

Если это поможет сузить поиск: source_url в манифесте — ...&view=table&words=..., то есть табличное представление; на дневную динамику нужна вкладка «Динамика».

Почему это блокирует

Мы (wordstat-trends) не можем собрать дневные фикстуры для проверки недельной сезонности sp=7 — это несущая часть гипотезы wordstat-trends#23. Окно дневных данных у Вордстата живёт 60 дней, поэтому попытки не бесконечны: чем дольше держится дефект, тем меньше остаётся календарного запаса на выровненное окно, кратное неделе.

Обходной путь на нашей стороне уже применён (используем фикстуры, собранные на 45512d4), так что срочности «прямо сейчас» нет — но собирать новые данные мы не можем.

[axisrow]

Закрывается как невоспроизводимая

Три живых прогона на авторизованном Chrome через CDP :9223, 0 из 3 воспроизвели DownloadTimeoutError:

1. Месячный, одна фраза, регион Россия, без --granularity — «Собрано 1 из 1», exit 0, ноль исключений. ⬇️ File download starting присутствует для всех четырёх видов, включая top_popular, за ним Download completed и Tracked download.
2. Дневной, пересчитанное окно — тот же результат.
3. Batch на всех трёх фразах репорта, дневной, окно 28.06–25.08, --timeout 90 — «Собрано 3 из 3, из них частично 1». DownloadTimeoutError — ноль совпадений во всём логе.

Почему точное окно репорта не проверено

Окно из репорта — 2026-06-22 … 2026-08-16. На дату закрытия (27.08.2026) его отклоняет наша собственная валидация в periods.py, ещё до обращения к браузеру: от date_from до сегодня 66 дней при лимите 60 для дневной гранулярности. Воспроизвести исходные параметры дословно физически невозможно — окно истекло.

Прогоны выполнялись на максимально близких окнах, сохраняющих суть запроса.

Что проверялось и отпало по ходу

Ни одна из гипотез не подтвердилась:

• Связь с fix: contain downloads to their own directory, keep partial results (#27) #28 (containment загрузок) — session.downloaded_files заполняется только при state=='completed', а сбежавший путь дал бы DownloadEscapedError, которого в репорте нет.
• Remote-ветка browser-use, синтезирующая путь — не исполняется: is_local=True выставлен в collector.py, downloads_watchdog.py ветвится по нему.
• source_url / view=table — пишется один раз на фразу.
• Дневная гранулярность как причина — сбой в репорте происходит на top_popular, до кода гранулярности.
• Скользящее 60-дневное окно — окно из репорта было строже прошедшего в тот же день по обеим границам.

Что расследование нашло взамен

Отдельные, подтверждённые дефекты, заведённые своими issue:

• bug: top_popular/top_related экспортируются пустыми при 200 строках в DOM (DOM≠экспорт, воспроизведено живьём 2/2) #31 — top_popular/top_related экспортируются пустыми (219/212 байт, только заголовок) при 200 реальных строках в DOM. Подтверждено ручной проверкой на одной вкладке тем же путём скачивания, что и продакшн-код. Исправлено PR fix: retry empty top exports from CSV content #33.
• flaky: regions падает InterfaceChangedError на переключении вида (1 сбой из 3 фраз в batch, паттерн не подтверждён) #32 — regions однократно упала InterfaceChangedError на переключении вида (1 сбой из 3 фраз). Паттерн не подтверждён.

Если симптом вернётся

Переоткрывать не нужно — лучше завести новую issue со свежим прогоном под BROWSER_USE_LOGGING_LEVEL=debug и ключевым вопросом: присутствует ли ⬇️ File download starting. Его наличие или отсутствие сразу разделяет «Chrome не начал загрузку» и «загрузка началась, но файл не доехал» — два разных дефекта, которые в исходном репорте неразличимы.

[axisrow]

Наблюдение от 31.08.2026 — не переоткрывает issue

При работе над #32 (на ревизии 12ce642, то есть со всеми исправлениями, включая ретрай пустых топов из PR #33) первая попытка полной сборки подвисла на ожидании CSV для top_popular.

Почему это НЕ классифицируется ни как #29, ни как #31:

• размер файла в момент прогона не зафиксирован — неизвестно, был ли он пустым (219 байт, признак bug: top_popular/top_related экспортируются пустыми при 200 строках в DOM (DOM≠экспорт, воспроизведено живьём 2/2) #31) или полноценным;
• до доменного исключения выполнение не дошло: прогон остановлен вручную (Ctrl-C), итог — /, а не (признак bug: дневной сбор падает DownloadTimeoutError на первом скачивании (регрессия после 45512d4, не исправлено #28) #29) и не ;
• временный каталог с артефактами удалён.

Файл при этом в каталоге присутствовал, а строку наблюдатель не видел — но логи не были выставлены в debug, так что отсутствие строки ничего не доказывает.

Вывод: данных для классификации недостаточно. Отдельная issue не заводится сознательно — она была бы невоспроизводимой и незакрываемой. Запись оставлена здесь на случай, если симптом повторится: тогда будет видно, что наблюдение не единично.

Что снять при повторении: размер скачанного файла, тип доменного исключения (не прерывая прогон вручную) и наличие под . Эти три признака разделяют #29, #31 и новый дефект.

[axisrow]

Наблюдение от 31.08.2026 — не переоткрывает issue

(предыдущий комментарий отображается с потерями — часть текста была съедена оболочкой при публикации; здесь он приведён полностью и заменяет тот)

При работе над #32, на ревизии 12ce642 — то есть со всеми исправлениями, включая ретрай пустых топов из PR #33 — первая попытка полной сборки подвисла на ожидании CSV для top_popular.

Что наблюдалось

• BrowserSession вывел Tracked download: wordstat_top_queries.csv;
• файл присутствовал в каталоге загрузок прогона;
• строку File download starting наблюдатель не видел — но логи не были выставлены в debug, поэтому её отсутствие ничего не доказывает.

Почему не классифицируется ни как #29, ни как #31

• размер файла не зафиксирован — неизвестно, был ли он пустым (219 байт, признак bug: top_popular/top_related экспортируются пустыми при 200 строках в DOM (DOM≠экспорт, воспроизведено живьём 2/2) #31) или полноценным;
• до доменного исключения выполнение не дошло: прогон остановлен вручную по Ctrl-C, итогом стали CancelledError / KeyboardInterrupt, а не DownloadTimeoutError (признак bug: дневной сбор падает DownloadTimeoutError на первом скачивании (регрессия после 45512d4, не исправлено #28) #29) и не InterfaceChangedError;
• временный каталог с артефактами удалён.

Вывод

Данных для классификации недостаточно. Отдельная issue сознательно не заводится: она была бы и невоспроизводимой, и незакрываемой. Запись оставлена здесь — если симптом повторится, будет видно, что наблюдение не единично.

Что снять при повторении

1. размер скачанного файла;
2. тип доменного исключения — не прерывая прогон вручную, дав коллектору дойти до собственной ошибки;
3. наличие File download starting под BROWSER_USE_LOGGING_LEVEL=debug.

Эти три признака разделяют #29, #31 и новый дефект.