Проблема была не в незаданной переменной, а в отсутствующей связности:
gendesign-redis-1 жил только в gendesign_default, tradein-backend — в
gendesign_shared + tradein-net. Общей сети нет → redis не резолвился ни под
каким именем. Вводим redis в gendesign_shared под алиасом gendesign-redis
(тот же приём, что уже применён к postgres) и только после этого задаём
REDIS_URL на db1 (db0 занят celery-брокером gendesign, db2 — glitchtip).
Порядок «сначала сеть, потом переменная» соблюдён буквально: связность
проверена на проде throwaway-контейнером ДО того, как переменная где-либо
появилась (из tradein-backend: PING 19 мс, SET 0.35 мс, GET 0.31 мс, db1).
Цена ошибки измерена тем же клиентом, что в app/services/cache.py:
localhost-отказ 16.6 мс (как было), NXDOMAIN 123.5 мс, а имя, которое
резолвится и не отвечает — 2003.7 мс. Последнее и есть та молчаливая яма,
про которую предупреждает issue: ×2 (GET+SET) на каждый запрос, без ошибки
наверх, потому что get/set глотают исключение.
Свой redis в стеке trade-in НЕ добавлен осознанно: deploy-tradein.yml
поднимает стек как `up -d --no-deps $SERVICES` с ЗАХАРДКОЖЕННЫМ списком
(browser backend frontend tgbot [scraper]). Новый сервис туда не попадает и
`--no-deps` его не подтянет — контейнер никогда бы не стартовал, а
REDIS_URL указывал бы в пустоту. Правка списка = правка deploy-tradein.yml,
который сейчас заморожен (#2680).
Ожидаемый выигрыш по скорости — НУЛЕВОЙ, и это измерено, а не оценено:
POST /api/v1/search за 16.2 суток логов Caddy получил 0 запросов, и во
фронтенде нет ни одного вызова этого роута. Реальная ценность правки —
снять заряженную ловушку и дать #2665 (потолок темпа логинов) хранилище с
ПРОВЕРЕННОЙ доступностью, чего issue прямо и требует.
Refs #2709, #2674, #2665
