`with ThreadPoolExecutor(...) as pool:` на выходе зовёт shutdown(wait=True) —
он ждёт, пока рабочий поток закончит сам. Поэтому future.result(timeout=T)
ограничивал только момент, когда мы перестаём ждать ЗНАЧЕНИЕ, а функция всё
равно не возвращалась, пока висел внешний вызов.
Два места, один класс:
- report_maps._add_basemap — докстрока обещает «недоступный tile-сервер не
подвесит воркер», а генерация отчёта стояла столько, сколько стояло
зависание;
- admin_scrape.queue_status — докстрока обещает «worst-case latency ≈ 600 ms
even if no worker is reachable». Ради этого inspect и уносили в поток; ручку
фронт опрашивает по таймеру, и висела она вместе с брокером.
В обоих случаях except-ветка существовала и выглядела рабочей — она просто
ничего не ограничивала. Поэтому тесты меряют ВРЕМЯ ВОЗВРАТА, а не наличие
обработчика.
ЧЕСТНАЯ ЦЕНА, названная в коде: shutdown(wait=False) оставляет зависший поток
дорабатывать в фоне. Ограничивается ЗАПРОС, но не процесс — потоки пула
не-демоны и джойнятся в atexit, так что остановка воркера всё ещё может
подождать зависший фетч. Это размен «висит генерация отчёта» → «висит один
поток в фоне», а не полное устранение. cancel_futures=True снимает только
ещё не начатые задачи: начатый поток Python прервать не умеет.
Тесты двусторонние: против main падают обе временные проверки, третья —
контроль «успешный путь по-прежнему даёт True» — зелёная с обеих сторон.
Зависание в тестах ограничено 3 секундами: тест обязан завершаться и на
сломанном коде, иначе красный прогон превращается в зависший.
Хунк форматирования — не мой: pre-commit ruff v0.7.4 против 0.15.12 (#2864).
Refs #2464
