# Backend NODES_NODE_USERS_QUEUE silently stops consuming after a Redis outage

**URL:** https://f.docs.rw/t/topic/717
**Category:** Баг-репорты
**Created:** 2026-09-11T04:48:26Z
**Posts:** 2

## Post 1 by @giontpartnership — 2026-09-11T04:48:26Z

> Полная версия с разбором по строкам исходников: [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](https://github.com/remnawave/backend/issues/216)

**Коротко.** После пересоздания контейнера 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](https://github.com/taskforcesh/bullmq/issues/4585), исправленная в 6.3.3 ([PR #4586](https://github.com/taskforcesh/bullmq/pull/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`](https://github.com/remnawave/backend/commit/989ca9f8d8f8a5be1a72b7dff76f58a0ce62d141) от 08.09 как рутинный «chore: update dependencies», без упоминания багфикса.

**Оговорки, чтобы не вводить в заблуждение.** Мы гоняли TCP-топологии, на unix-сокете не проверяли и не утверждаем, что там то же самое.

---

## Post 2 by @remnawave — 2026-09-12T15:11:09Z

Версия **3.4.4** доступна в релизе.

---

## Post 3 by @system — 2026-09-14T15:12:04Z

Эта тема была автоматически закрыта через 2 дня после последнего ответа. В ней больше нельзя отвечать.