Какой баг показался интересным?

Интересный баг: некорректное взаимодействие систем при ленивой загрузке графа зависимостей

Один из самых интересных и сложных багов, которые я исследовал, был связан с ленивой загрузкой (lazy loading) в микросервисной архитектуре. Система состояла из нескольких сервисов, которые обменивались данными через REST API и формировали сложный граф зависимостей для построения отчетов. Баг проявлялся в недетерминированном поведении системы: при одинаковых входных данных отчет генерировался корректно в 70% случаев, а в 30% — содержал частично пустые или некорректные данные.

Корень проблемы: race condition при параллельных запросах

После глубокого анализа логирования, мониторинга и кода, проблема была локализована в механизме ленивой загрузки зависимостей. Система использовала паттерн, где каждый сервис при необходимости данных из другого сервиса делал асинхронный запрос. Однако при построении графа, некоторые узлы запускали параллельные запросы к одному и тому же сервису, но с разными параметрами, зависящими от предыдущих шагов.

Ключевой код (симулирующий проблему) выглядел так:

class ReportBuilder:
    def __init__(self):
        self.cache = {}

    async def fetch_data(self, service_url, params):
        # Асинхронный запрос к внешнему сервису
        response = await async_http_client.get(service_url, params=params)
        return response.json()

    async def build_node(self, node_id):
        if node_id in self.cache:
            return self.cache[node_id]

        # Первый запрос для базовых данных узла
        base_data = await self.fetch_data('service_a/data', {'node': node_id})
        
        # Ленивая загрузка зависимостей: параллельные запросы к service_b
        dependencies_tasks = []
        for dep_id in base_data['dependencies']:
            task = self.fetch_data('service_b/details', {'dep': dep_id, 'context': base_data['context_key']})
            dependencies_tasks.append(task)
        
        dependencies_results = await asyncio.gather(*dependencies_tasks)
        
        # Обработка результатов
        processed_data = self.process_data(base_data, dependencies_results)
        self.cache[node_id] = processed_data
        return processed_data

Проблема была в параметре 'context': base_data['context_key']. context_key генерировался сервисом A на основе своего внутреннего состояния и времени запроса. В условиях высокой нагрузки сервис A иногда выдавал разные context_key для двух параллельных запросов от одного узла графа, происходивших почти одновременно. Это приводило к тому, что сервис B получал запросы с разными контекстами, и его ответы становились несовместимыми друг с другом, нарушая целостность данных узла.

Решение и выводы

Решение включало несколько этапов:

• Добавление синхронизации на уровне построения узла: гарантия, что для одного узла все запросы зависимостей получают одинаковый context_key.
• Введение механизма "контекстной сессии" на стороне сервиса A, чтобы группировать связанные запросы.
• Улучшение тестов: создание нагрузочных тестов, специфически воспроизводящих race condition.

# Исправленный код с синхронизацией
async def build_node(self, node_id):
    if node_id in self.cache:
        return self.cache[node_id]

    base_data = await self.fetch_data('service_a/data', {'node': node_id})
    context_key = base_data['context_key']
    
    # Все запросы зависимостей используют ОДИН контекст, полученный из base_data
    dependencies_tasks = []
    for dep_id in base_data['dependencies']:
        task = self.fetch_data('service_b/details', {'dep': dep_id, 'context': context_key})
        dependencies_tasks.append(task)
    
    dependencies_results = await asyncio.gather(*dependencies_tasks)
    processed_data = self.process_data(base_data, dependencies_results)
    self.cache[node_id] = processed_data
    return processed_data

Этот баг был интересен потому, что:

• Он затрагивал неочевидное взаимодействие между системами, где проблема была не в одном сервисе, а вprotocol их общения.
• Проявлялся статистически, что делало его воспроизведение и локализацию сложной задачей.
• Требовал понимания асинхронного программирования, механизмов кеширования и параллельных вычислений.
• Показал важность нагрузочного и стресс-тестирования для выявления проблем, связанных с состоянием и временем.
• Укрепил принцип, что в распределенных системах идемпотентность запросов и консистентность контекста — критически важны для надежности.

Работа с таким багом подчеркивает, что роль QA Engineer часто выходит за рамки простой проверки функционала и включает глубокий анализ архитектурных решений и их влияния на устойчивость системы в реальных условиях.