- Добавлена полная интеграция с Telegram Mini App (динамическая загрузка SDK) - Отдельный компактный дизайн для Telegram Mini App - Добавлен loader при инициализации (предотвращает мелькание SMS-авторизации) - Улучшена навигация: кнопки "Назад" и "К списку заявок" теперь сохраняют авторизацию - Telegram Mini App: кнопка "Выход" просто закрывает приложение - Telegram Mini App: заявки "В работе" скрыты из списка - Веб-версия: для заявок "В работе" добавлена кнопка "Просмотреть в Telegram" (ссылка на @klientprav_bot) - Telegram Mini App: кнопки действий в черновиках расположены вертикально - Веб-версия: убрано отображение номера телефона в приветствии - Исправлена проблема с возвратом к списку черновиков (не требует повторной SMS-авторизации) - Заблокировано удаление и редактирование заявок со статусом "В работе" - Добавлена документация по Telegram Mini App интеграции
148 lines
6.2 KiB
Markdown
148 lines
6.2 KiB
Markdown
# 🔧 Решение проблемы зависших n8n workflow
|
||
|
||
## 🐛 Проблема
|
||
|
||
Workflow в n8n зависает и не может быть перезапущен даже через интерфейс. Redis Trigger node теряет соединение и не переподключается автоматически.
|
||
|
||
## ✅ Что сделано
|
||
|
||
### 1. Улучшена логика перезапуска workflow
|
||
|
||
**Файл:** `backend/app/services/n8n_service.py`
|
||
|
||
**Изменения:**
|
||
- ✅ Увеличены таймауты с 10 до 30 секунд (общий) и 15 секунд (для отдельных операций)
|
||
- ✅ Добавлена обработка таймаутов при деактивации (продолжаем даже если деактивация зависла)
|
||
- ✅ Увеличена задержка между деактивацией и активацией (3 секунды вместо 2)
|
||
- ✅ Добавлена дополнительная задержка после активации для инициализации trigger node
|
||
- ✅ Улучшено логирование ошибок с полным traceback
|
||
|
||
### 2. Улучшена проверка и перезапуск в фоне
|
||
|
||
**Файл:** `backend/app/api/claims.py`
|
||
|
||
**Изменения:**
|
||
- ✅ Добавлены повторные попытки перезапуска (до 2 попыток)
|
||
- ✅ Добавлена проверка подписчиков после перезапуска
|
||
- ✅ Улучшено логирование процесса перезапуска
|
||
|
||
## 🚀 Как это работает
|
||
|
||
1. **При публикации сообщения в Redis:**
|
||
- Проверяется количество подписчиков
|
||
- Если подписчиков нет → сообщение сохраняется в буфер
|
||
- Запускается фоновая задача перезапуска workflow
|
||
|
||
2. **Процесс перезапуска:**
|
||
- Проверяется Redis lock (защита от частых перезапусков)
|
||
- Проверяется статус workflow через API
|
||
- Деактивируется workflow (даже если завис)
|
||
- Ждёт 3 секунды
|
||
- Активирует workflow
|
||
- Ждёт 2 секунды для инициализации
|
||
- Проверяет подписчиков
|
||
- Отправляет сообщения из буфера
|
||
|
||
3. **Повторные попытки:**
|
||
- Если первая попытка не удалась → повтор через 5 секунд
|
||
- Максимум 2 попытки
|
||
|
||
## 📊 Мониторинг
|
||
|
||
### Проверка подписчиков вручную:
|
||
|
||
```bash
|
||
redis-cli -h crm.clientright.ru -p 6379 -a "CRM_Redis_Pass_2025_Secure!" PUBSUB NUMSUB "ticket_form:description"
|
||
```
|
||
|
||
### Проверка статуса workflow:
|
||
|
||
```bash
|
||
curl -H "X-N8N-API-KEY: ..." "https://n8n.clientright.pro/api/v1/workflows/b4K4u851b4JFivyD" | jq '.active'
|
||
```
|
||
|
||
### Логи backend:
|
||
|
||
```bash
|
||
tail -f /var/www/fastuser/data/www/crm.clientright.ru/ticket_form/backend.log | grep -i "workflow\|redis\|subscriber"
|
||
```
|
||
|
||
## 🛠️ Если проблема повторится
|
||
|
||
### Вариант 1: Перезапуск через API (автоматически)
|
||
|
||
Код теперь автоматически пытается перезапустить workflow при обнаружении проблемы.
|
||
|
||
### Вариант 2: Ручной перезапуск через API
|
||
|
||
```bash
|
||
# Деактивировать
|
||
curl -X POST -H "X-N8N-API-KEY: ..." \
|
||
"https://n8n.clientright.pro/api/v1/workflows/b4K4u851b4JFivyD/deactivate"
|
||
|
||
# Подождать 5 секунд
|
||
sleep 5
|
||
|
||
# Активировать
|
||
curl -X POST -H "X-N8N-API-KEY: ..." \
|
||
"https://n8n.clientright.pro/api/v1/workflows/b4K4u851b4JFivyD/activate"
|
||
```
|
||
|
||
### Вариант 3: Перезапуск n8n (крайний случай)
|
||
|
||
Если workflow всё ещё завис, может потребоваться перезапуск самого n8n:
|
||
|
||
```bash
|
||
# Если n8n в Docker
|
||
docker restart <n8n_container>
|
||
|
||
# Если n8n как системный сервис
|
||
systemctl restart n8n
|
||
```
|
||
|
||
## 🔍 Диагностика
|
||
|
||
### Проверка что workflow активен но не слушает:
|
||
|
||
```bash
|
||
# 1. Проверить статус workflow
|
||
curl -H "X-N8N-API-KEY: ..." \
|
||
"https://n8n.clientright.pro/api/v1/workflows/b4K4u851b4JFivyD" | jq '{active: .active, updatedAt: .updatedAt}'
|
||
|
||
# 2. Проверить подписчиков
|
||
redis-cli -h crm.clientright.ru -p 6379 -a "..." PUBSUB NUMSUB "ticket_form:description"
|
||
|
||
# 3. Если active=true но подписчиков 0 → workflow завис
|
||
```
|
||
|
||
### Проверка Redis соединений:
|
||
|
||
```bash
|
||
redis-cli -h crm.clientright.ru -p 6379 -a "..." CLIENT LIST | grep "sub=1"
|
||
```
|
||
|
||
## 📝 Рекомендации на будущее
|
||
|
||
1. **Мониторинг:**
|
||
- Настроить автоматический мониторинг подписчиков (cron каждые 5 минут)
|
||
- Алерты при отсутствии подписчиков более 10 минут
|
||
|
||
2. **Автоматический перезапуск n8n:**
|
||
- Настроить health check для n8n
|
||
- Автоматический перезапуск при обнаружении проблем
|
||
|
||
3. **Логирование:**
|
||
- Включить детальное логирование в n8n
|
||
- Мониторинг логов на ошибки Redis соединений
|
||
|
||
4. **Настройка Redis:**
|
||
- Увеличить `tcp-keepalive` для стабильности соединений
|
||
- Настроить `timeout` для неактивных соединений
|
||
|
||
## 🔗 Связанные файлы
|
||
|
||
- `backend/app/services/n8n_service.py` - логика перезапуска workflow
|
||
- `backend/app/api/claims.py` - проверка подписчиков и запуск перезапуска
|
||
- `docs/N8N_REDIS_TRIGGER_TROUBLESHOOTING.md` - общая диагностика Redis Trigger
|
||
- `docs/N8N_MEMORY_ISSUES.md` - проблемы с памятью в n8n
|