Полная версия с разбором по строкам исходников: Backend 3.3.0–3.4.3: NODES_NODE_USERS_QUEUE silently stops consuming after a Redis outage (bullmq < 6.3.3) · Issue #216 · remnawave/backend · GitHub
Коротко. После пересоздания контейнера Redis панель перестаёт доставлять пользователей на ноды. Подписка выдаётся и корректно открывается в клиенте, но UUID не попадает ни на одну ноду, поэтому все серверы показывают n/a. Ни ошибки, ни строки об успехе в логах нет. Лечится только перезапуском контейнера панели.
Окружение. backend 3.4.3 (remnawave/backend:3), bullmq 6.3.2, ioredis 5.11.1, @remnawave/node-contract 3.4.1. Redis — valkey/valkey:9-alpine по TCP через REDIS_HOST/REDIS_PORT. Нода на remnawave/node 3.4.1 + Xray 26.7.28.
Что наблюдали. Контейнер Redis был пересоздан на работающей панели. Полсекунды ошибок подключения, дальше тишина. С этого момента воркер очереди NODES_NODE_USERS_QUEUE перестал брать задания: не доезжали ни добавления, ни удаления пользователей. Остальные очереди в том же процессе процессора работали весь период: health-check нод, start-node, start-all-nodes-by-profile, сбор статистики. Панель и API тоже работали штатно. Закончилось после docker restart remnawave.
2026-09-07 09:32:12 getaddrinfo ENOTFOUND remnawave-redis x65 за ~0.5 с
2026-09-07 09:32:12 [ioredis] Unhandled error event x4
2026-09-07 09:32:12 Memory cache subscriber ready x4
--- дальше ни одной строки, связанной с доставкой пользователей ---
Четыре строки Memory cache subscriber ready — это четыре процесса Node, которые переподключились. То есть снаружи панель выглядит полностью восстановившейся.
Причина. Регрессия bullmq #4585, исправленная в 6.3.3 (PR #4586). Простаивающий воркер висит в BZPOPMIN, сторожевой таймер вызывает disconnect(false) на его блокирующем клиенте, и если ioredis в этот момент в состоянии reconnecting, таймер переподключения стирается без события close — клиент остаётся в reconnecting навсегда. При этом Worker.isRunning() возвращает true, ошибок не эмитится, queue.add со стороны API работает, wait растёт, active остаётся нулевым. Помогает только перезапуск процесса.
Затронутые релизы. 3.3.0–3.3.2 пинят bullmq 6.1.2, 3.4.0–3.4.3 — 6.3.2. Все внутри окна 6.0.7…6.3.2. 3.4.3 — последний релиз, теги :3 и :latest указывают на него, то есть под ударом все текущие инсталляции.
Как повторить. Поднять затронутый backend с Redis по TCP и хотя бы одной нодой. Остановить или пересоздать контейнер Redis и продержать недоступным больше 10 секунд, панель при этом не трогать. Дождаться, пока бёрст ошибок в логе утихнет. Создать пользователя или перевыпустить подписку. На Redis: LLEN bull:NODES_NODE_USERS_QUEUE:wait растёт с каждой операцией, :active нулевой, на ноде пользователь не появляется.
Просьба. Патч-релиз на 3.4.x с bullmq >= 6.3.3. В dev нужная версия уже стоит: 6.3.4 пришла коммитом 989ca9f8 от 08.09 как рутинный «chore: update dependencies», без упоминания багфикса.
Оговорки, чтобы не вводить в заблуждение. Мы гоняли TCP-топологии, на unix-сокете не проверяли и не утверждаем, что там то же самое.