check-services: стабилизировать холодную проверку Superset #172

New Issue

2026-08-27T12:01:22+03:00

ddmitry commented

2026-08-27 12:01:22 +03:00

Цель

Убрать ложный красный результат make check-services, когда исправный холодный импорт Superset не укладывается в 30 секунд. Красный прогон должен означать поломку Superset или его подключения, а не случайную цену запуска Python-приложения.

Учебный результат: менти может доверять межсервисной проверке и разбирает красный Superset как дефект стенда, а не как гонку с тайм-аутом.

Наблюдение

На приемке #156 два штатных make check-services дали 5/1: проверка метаданных не получила вывод процесса, убитого внешним timeout 30s. В отдельном замере импорт модулей занял 22,312 с, create_app() завершился на 30,574 с, процесс вернул 124. Та же проверка с пределом 90 с прошла 3/0; последующий неизмененный make check-services прошел 7/7 за 129 с.

Узкое место - stored_config в check_superset() (scripts/stand-services.sh): одноразовый python -c создает приложение Superset под timeout 30s. Минимальная гипотеза - увеличить только этот предел по свежему замеру. Сначала проверить, что время уходит именно туда и что более узкого исправления нет.

Критерии приемки

Первый make check-services после перезапуска Superset и еще два последовательных прогона зеленые; каждый сохраняет счет 7/7.
Предел ожидания проверки метаданных обоснован замером холодного и теплого запусков, а не взят из соседней команды.
Контрольная поломка ожидаемого UUID или URI по-прежнему красит именно проверку метаданных и называет полученные значения.
make smoke остается быстрым и не получает тяжелую проверку Superset из check-services.
Замер и принятое решение записаны в docs/architecture/testing.md.

Границы

Не менять образ, конфигурацию или прикладные метаданные Superset без отдельного доказанного дефекта.
Не увеличивать остальные тайм-ауты stand-services.sh заодно.
Не добавлять повторы, которые скрывают настоящий отказ; один запуск должен иметь достаточный и объясненный предел.
make clean не нужен: проверяется процесс Superset, а не постоянное состояние всего стенда.

Сначала прочитать

scripts/stand-services.sh, функция check_superset.
docs/architecture/testing.md: карта make check-services и запись приемки #156.
PR #171, комментарий с триажем дополнительного ревью Fable.

Проверка

make config-test
make smoke
make check-services после перезапуска Superset и еще два раза подряд
контрольный красный прогон с временно неверным ожидаемым UUID или URI

## Цель Убрать ложный красный результат `make check-services`, когда исправный холодный импорт Superset не укладывается в 30 секунд. Красный прогон должен означать поломку Superset или его подключения, а не случайную цену запуска Python-приложения. Учебный результат: менти может доверять межсервисной проверке и разбирает красный Superset как дефект стенда, а не как гонку с тайм-аутом. ## Наблюдение На приемке #156 два штатных `make check-services` дали 5/1: проверка метаданных не получила вывод процесса, убитого внешним `timeout 30s`. В отдельном замере импорт модулей занял 22,312 с, `create_app()` завершился на 30,574 с, процесс вернул `124`. Та же проверка с пределом 90 с прошла 3/0; последующий неизмененный `make check-services` прошел 7/7 за 129 с. Узкое место - `stored_config` в `check_superset()` (`scripts/stand-services.sh`): одноразовый `python -c` создает приложение Superset под `timeout 30s`. Минимальная гипотеза - увеличить только этот предел по свежему замеру. Сначала проверить, что время уходит именно туда и что более узкого исправления нет. ## Критерии приемки - [x] Первый `make check-services` после перезапуска Superset и еще два последовательных прогона зеленые; каждый сохраняет счет 7/7. - [x] Предел ожидания проверки метаданных обоснован замером холодного и теплого запусков, а не взят из соседней команды. - [x] Контрольная поломка ожидаемого UUID или URI по-прежнему красит именно проверку метаданных и называет полученные значения. - [x] `make smoke` остается быстрым и не получает тяжелую проверку Superset из `check-services`. - [x] Замер и принятое решение записаны в `docs/architecture/testing.md`. ## Границы - Не менять образ, конфигурацию или прикладные метаданные Superset без отдельного доказанного дефекта. - Не увеличивать остальные тайм-ауты `stand-services.sh` заодно. - Не добавлять повторы, которые скрывают настоящий отказ; один запуск должен иметь достаточный и объясненный предел. - `make clean` не нужен: проверяется процесс Superset, а не постоянное состояние всего стенда. ## Сначала прочитать - `scripts/stand-services.sh`, функция `check_superset`. - `docs/architecture/testing.md`: карта `make check-services` и запись приемки #156. - PR #171, комментарий с триажем дополнительного ревью Fable. ## Проверка - `make config-test` - `make smoke` - `make check-services` после перезапуска Superset и еще два раза подряд - контрольный красный прогон с временно неверным ожидаемым UUID или URI

ddmitry added the ready-for-agent label 2026-08-27 12:01:22 +03:00

ddmitry referenced this issue

2026-08-27 12:23:47 +03:00

feat(etl): добавлен дневной конвейер трансформаций #171

ddmitry referenced this issue

2026-08-28 11:10:16 +03:00

Этап 4: трансформации и витрины, сверка A+C #6

ddmitry referenced a pull request that will close this issue

2026-08-28 12:32:22 +03:00

fix(superset): стабилизирована проверка рабочего контура #176

ddmitry closed this issue

2026-08-28 12:41:28 +03:00