Wait-стратегии: когда сервис готов

Фиксированная пауза — самый дорогой способ решить задачу ожидания контейнера go. Поставьте паузу на пять секунд: на локальной Docker-машине сервис готов через восемьсот миллисекунд, и каждая лишняя секунда — плата за прогон, размноженная числом тестов; на перегруженном CI всё наоборот — двадцать секунд миграции не влезли в вашу паузу, и тест падает без всякой вины сервиса. Флейк из-за сна коварнее остальных: он зелёный девять прогонов из десяти, и ловят его на ветке релиза. Стратегия меняет саму постановку: не «сколько подождать», а «какое событие означает готовность». Тест спит ровно ноль: опрос идёт каждые сто миллисекунд, и управление возвращается в момент события — не раньше и не позже. Побочный бонус — диагностика: стратегия попадает в лог прогона своим описанием вида «log message ready» или «port 5432/tcp to be listening», так что при падении видно, какое условие не сошлось, а не гадание по таймеру. Отсюда и побочный эффект: конфигурация теста перестаёт зависеть от мощности машины — один и тот же прогон занимает одинаковое время на ноутбуке и в CI, потому что нигде не хранится магическое число секунд, подобранное наугад.

Стратегия порта проверяет готовность в два слоя. Внешний — со стороны хоста: библиотека достаёт маппнутый порт и диалится по TCP, как это сделал бы настоящий клиент; соединение refused — значит, сервис ещё не слушает. Внутренний — изнутри контейнера: запускается короткая команда на /bin/sh, которая смотрит /proc/net/tcp, пробует nc и bash-овский /dev/tcp — открыт ли порт на интерфейсах контейнера. Двухслойность спасает от случая, когда Docker смаппировал порт, а процесс ещё не привязался к нему. У образов без шелла внутренняя проверка не пройдёт в принципе: библиотека заметит код выхода 126 или 127, напишет в лог и продолжит валидировать только внешний доступ — стратегия не ломается, но знать про это поведение полезно. Для нестандартных ситуаций есть переключатели: SkipInternalCheck пригодится, когда сервис привязывает порт позже дополнительных условий, ForMappedPort вообще не трогает порт и ждёт только завершение маппинга, а ForExposedPort ждёт первый объявленный порт, если указывать конкретный незачем. Знание этого двухслойного протокола пригодится при отладке: если тест завис в ожидании порта, смотрите, на каком слое застряли, — в логах прогона видны попытки внешнего диала и внутренние exec-команды.

Порт отвечает раньше, чем сервис готов принимать полезную нагрузку, поэтому событийные стратегии часто честнее. ForLog читает docker logs и ждёт подстроку: модуль Redis ловит фирменную строку готовности Redis, а модуль Postgres — «database system is ready to accept connections» с WithOccurrence(2), потому что Postgres печатает её дважды при восстановлении. Подстрока ищется чувствительно к регистру; нужен шаблон — AsRegexp переключает стратегию на регулярное выражение. ForHTTP шлёт настоящие запросы: ForHTTP на путь healthz ходит на наименьший открытый TCP-порт, ждёт статус из StatusCodeMatcher — по умолчанию 200 — и опционально сверяет тело через WithResponseMatcher; порт уточняется WithPort, метод — WithMethod, Basic-доступ — WithBasicAuth, а WithForcedIPv4LocalHost чинит docker-баги с IPv6. ForSQL поднимает планку до уровня протокола: ForSQL принимает порт, имя драйвера и функцию сборки URL и до победы выполняет SELECT 1 через database/sql — драйвер должен быть зарегистрирован, а запрос меняется WithQuery. Модуль CockroachDB именно так ждёт движок: HTTP на health плюс ForSQL с драйвером pgx. Из той же серии ForExit — ожидание, пока контейнер завершится сам: идеально для одноразовых задач вроде миграций, где успех — это именно выход.

Реальному сервису мало одного условия, и вот здесь включаются комбинаторы. ForAll — конъюнкция: стратегии исполняются по очереди, и ожидание пройдёт, когда каждая вернёт nil; порядок имеет значение — порт логично проверить раньше HTTP-пробы, чтобы запросы не улетали в ещё закрытый порт. Общий бюджет задаёт WithDeadline: дедлайн накрывает все вложенные стратегии разом, а WithStartupTimeoutDefault подставляет таймаут только тем из них, у которых личного нет. ForAny — дизъюнкция: каждая стратегия стартует в своей горутине, первый успех отменяет остальные, и ожидание завершается. У дизъюнкции жёсткая семантика провала: любая стратегия, вернувшая ошибку, немедленно роняет всё ожидание, даже если соседняя вот-вот бы прошла, — ретраев внутри комбинатора нет. Устаревший WithStartupTimeout у ForAll не сломает старый код: он просто передаёт значение в WithDeadline, и набор по-прежнему ограничивается целиком. Приятная мелочь: nil-элементы внутри списка комбинатор молча пропускает — модуль может дописывать стратегии по ходу инициализации, не проверяя каждый элемент на пустоту. Практический ориентир: два-три условия легко живут в ForAll с одним дедлайном; больше — повод задуматься, не ждёте ли вы взаимоисключающих событий, и не превратится ли набор в вечный список, где одно условие не сработает никогда.

У каждой стратегии личный таймаут старта — по умолчанию шестьдесят секунд — и опрос каждые сто миллисекунд. WithStartupTimeout сужает личный бюджет: Redis-модуль даёт порту десять секунд, LocalStack просит сто двадцать на HTTP-пробу — тяжёлые образы просто не успевают за дефолтом. На комбинаторах арифметика другая: WithDeadline накрывает весь набор целиком и не складывается с личными таймаутами — сработает более короткий контекст. Интервал опроса — отдельная ручка WithPollInterval: сотня миллисекунд хороша для дешёвых проверок, но HTTP-проба ходит по сети на каждой итерации, и для неё ставят полсекунды или секунду. Щедрый таймаут вредит не меньше короткого: реальный сбой вместо быстрого красного теста минуту держит прогон в тишине, умножая это на число тестов. Отмена идёт через контекст, и при истечении бюджета ошибка уносит число сделанных попыток и последнюю причину — разбор не начинается с нуля. Страховка снизу тоже есть: пока стратегия ждёт, библиотека сверяет состояние контейнера, и процесс, умерший от OOM или завершившийся с кодом, возвращает ошибку немедленно — молчаливого ожидания мёртвого контейнера не случится. Заметьте: HTTP-проба ограничена и собственным таймаутом клиента в секунду на запрос — зависший сервис не заблокирует опрос дольше этого окна, и стратегия просто сделает следующую попытку.