Приведи пример серьёзного бага,но не приоритетного

Пример серьёзного, но неприоритетного бага в веб-приложении

В контексте управления приоритетами, серьёзность (severity) отражает влияние бага на систему (например, падение сервера, потеря данных), а приоритет (priority) — срочность его исправления с точки зрения бизнеса или пользователей. Один из ярких примеров такого диссонанса — утечка памяти в фоновом процессе веб-приложения, которая не влияет на основную функциональность, но медленно деградирует производительность.

Контекст и описание бага

В крупном SPA (Single Page Application) для управления проектами есть функция «живого» обновления данных через WebSocket. Каждые 30 секунд клиент получает обновления по задачам без перезагрузки страницы. Со временем, если пользователь работает в приложении несколько часов подряд, потребление оперативной памяти браузером неуклонно растёт (например, с 200 МБ до 2+ ГБ за 8 часов). Это происходит из-за того, что обработчики событий WebSocket и кэшированные объекты в JavaScript не освобождаются сборщиком мусора. В итоге браузер начинает тормозить, а через очень длительное время может аварийно закрыть вкладку.

Техническая детализация

Багу присваивается Severity: High (так как это приводит к критической деградации производительности и потенциальному краху клиентской части), но Priority: Low/Medium. Причина низкого приоритета:

• Буг проявляется только после многих часов непрерывной работы (не влияет на типичные сессии длительностью 1–2 часа).
• Нет потери данных — при перезагрузке вкладки всё восстанавливается.
• Бизнес-логика и основные функции (создание задач, отчётность) остаются работоспособными.
• Исправление требует глубокого рефакторинга механизма подписки/отписки событий, что сопряжено с рисками для более важного функционала.

Пример кода, иллюстрирующий проблему

// Пример проблемного кода в модуле live-updates.js
class LiveDataFeed {
    constructor() {
        this.socket = new WebSocket('wss://api.example.com/updates');
        this.cache = new Map();
        // ОШИБКА: обработчик добавляется, но никогда не удаляется
        this.socket.onmessage = (event) => {
            const data = JSON.parse(event.data);
            this.updateCache(data);
            // Побочный эффект: рендер исторических данных
            this.renderHistoricalData(data);
        };
    }

    updateCache(data) {
        // Кэш растёт бесконечно, старые записи не удаляются
        this.cache.set(data.id, data);
    }

    renderHistoricalData(data) {
        // Создаём DOM-элементы, которые могут не удаляться
        const element = document.createElement('div');
        element.innerHTML = `Data: ${data.value}`;
        document.querySelector('#history-log').appendChild(element);
    }

    // НЕТ метода destroy() для очистки сокета и кэша
}

// При каждом переходе пользователя между разделами приложения
// может создаваться новый экземпляр LiveDataFeed, а старый остаётся в памяти

В этом коде:

• Нет механизма отписки от WebSocket.
• Кэш Map растёт без ограничений.
• DOM-элементы накапливаются без очистки.

Почему это серьёзно, но исправление откладывается?

Серьёзность:

• Деградация производительности всей вкладки браузера.
• Негативный пользовательский опыт для power users (например, менеджеров проектов, работающих целый день).
• Риск краха клиента на слабых устройствах.

Низкий приоритет:

1. Ограниченный охват пользователей: только 5–10% активных пользователей работают достаточно долго для проявления бага.
2. Есть временное решение: можно добавить подсказку «Рекомендуем периодически обновлять страницу» в интерфейс.
3. Высокая стоимость исправления: требует тестирования всех сценариев работы с WebSocket, что отвлекает команду от задач с более прямым бизнес-воздействием (например, от новой функции оплаты).
4. Риски регрессии: изменения в core-механизме событий могут сломать другие модули.

Вывод

Такой баг часто попадает в бэклог продукта и исправляется в рамках технического долга, когда есть окно между спринтами. Он демонстрирует, как технически сложная проблема с серьёзными последствиями может отодвигаться бизнес-логикой, что требует от QA-инженера чёткого обоснования severity и готовности к компромиссам с менеджментом.