(low) queue_status: broker-failure except-блоки без логирования (silent swallow в UI hot-path) #1395

New issue

Closed

opened 2026-06-14 18:11:23 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-14 18:11:23 +00:00

Collaborator

Описание

В queue_status helper _safe() (строки 177-181) и блок queue_depth (строки 201-206) ловят broad Exception и возвращают None без какого-либо вызова logger. Деградация (return None при недоступном broker) намеренна и приемлема для UI-poll эндпоинта, но полное отсутствие лог-строки означает, что устойчиво сломанное Redis/broker-соединение невидимо в логах — операторы видят пустые workers и null queue_depth без диагностического следа. Функционально корректно; пробел в observability.

Корень

В файле нет импорта/определения logger вообще, поэтому при срабатывании любого из двух except-блоков нет нулевой обсервабилити. Нарушает проектную конвенцию .claude/rules/backend.md: «❌ except Exception: pass без re-raise или logger.exception».

Evidence

admin_scrape.py:177-181:

def _safe(fn):
    try:
        return fn()
    except Exception:
        return None

admin_scrape.py:201-206:

try:
    with celery_app.connection_or_acquire() as conn:
        with conn.channel() as channel:
            queue_depth = channel.client.llen("celery")
except Exception:
    queue_depth = None

Suggested fix

Добавить в оба except-блока лог-строку при сохранении return None, например logger.warning("queue_status broker probe failed", exc_info=True) или logger.debug(...) (чтобы избежать спама от частого UI-poll), чтобы устойчивый broker-outage оставлял след. Предварительно завести logger = logging.getLogger(__name__) в модуле.

Severity-обоснование

low: нет функционального слома — чистый observability-gap. Но дефект реальный, достижимый и нарушает заявленную проектную конвенцию.

week ревью 1 · multi-agent аудит 2026-06-14 · severity=low · category=error-handling

Затронутые файлы:

/Users/anton/Птица/gendesign/backend/app/api/v1/admin_scrape.py

## Описание В `queue_status` helper `_safe()` (строки 177-181) и блок queue_depth (строки 201-206) ловят broad `Exception` и возвращают None без какого-либо вызова logger. Деградация (return None при недоступном broker) намеренна и приемлема для UI-poll эндпоинта, но полное отсутствие лог-строки означает, что устойчиво сломанное Redis/broker-соединение невидимо в логах — операторы видят пустые `workers` и `null` `queue_depth` без диагностического следа. Функционально корректно; пробел в observability. ## Корень В файле нет импорта/определения `logger` вообще, поэтому при срабатывании любого из двух except-блоков нет нулевой обсервабилити. Нарушает проектную конвенцию `.claude/rules/backend.md`: «❌ `except Exception: pass` без re-raise или `logger.exception`». ## Evidence `admin_scrape.py:177-181`: ```python def _safe(fn): try: return fn() except Exception: return None ``` `admin_scrape.py:201-206`: ```python try: with celery_app.connection_or_acquire() as conn: with conn.channel() as channel: queue_depth = channel.client.llen("celery") except Exception: queue_depth = None ``` ## Suggested fix Добавить в оба except-блока лог-строку при сохранении return None, например `logger.warning("queue_status broker probe failed", exc_info=True)` или `logger.debug(...)` (чтобы избежать спама от частого UI-poll), чтобы устойчивый broker-outage оставлял след. Предварительно завести `logger = logging.getLogger(__name__)` в модуле. ## Severity-обоснование **low**: нет функционального слома — чистый observability-gap. Но дефект реальный, достижимый и нарушает заявленную проектную конвенцию. --- _week ревью 1 · multi-agent аудит 2026-06-14 · severity=**low** · category=`error-handling`_ Затронутые файлы: - `/Users/anton/Птица/gendesign/backend/app/api/v1/admin_scrape.py`