Приведи пример интересного бага

Пример интересного бага из моей практики

За 10+ лет работы я встретил множество багов. Но самые интересные — это те, которые требуют глубокого анализа и которые раскрывают архитектурные проблемы. Расскажу о реальном примере.

Баг: Race condition при одновременных платежах

Контекст: Работал на финтех платформе, где пользователи делают платежи. Баг был трудноуловимый и проявлялся редко.

Описание проблемы: При одновременной отправке двух платежей (дабл-клик на кнопку) оба платежа проходили, хотя средств было только для одного.

Как я это нашёл:

1. Получил жалобу: списали 2000 руб., но отправил один платёж
2. Проверил логи API — два POST запроса за 50ms
3. Проверил БД — два платежа со статусом COMPLETED
4. Баланс счёта — отрицательный!

Рут-кауз (Root Cause):

В коде была проверка баланса, потом его уменьшение. Между ними — race condition:

Request 1: Проверка balance = 1000, достаточно ✓ Request 2: Проверка balance = 1000 (still!), достаточно ✓ Request 1: balance = 100 Request 2: balance = -800 (БАГ!)

Баг-репорт:

ID: BUG-2024-RACE-001 Severity: CRITICAL (финансовые потери) Priority: CRITICAL

Title: Race condition при одновременных платежах

Description: При двух одновременных POST запросах на /api/v1/payments оба платежи проходят, даже если общая сумма превышает баланс.

Steps:

1. Создать пользователя с balance = 1000 руб.
2. Отправить два одновременных POST запроса /api/v1/payments с amount = 900
3. Проверить баланс

Expected:

• Один платёж пройдёт (200)
• Второй отклонится (400, insufficient_funds)
• Баланс = 100

Actual:

• Оба платежа проходят (200)
• Баланс = -800

Impact: Потребители могут отправлять платежи больше чем у них есть

Решение (Fix):

Разработчик применил pessimistic locking (SELECT FOR UPDATE в PostgreSQL):

Теперь: Request 1: Берёт lock на строку, проверка: 1000 ≥ 900 ✓, вычитает Request 2: Ждёт lock, получает: баланс 100, проверка: 100 ≥ 900 ✗, возвращает 400

Почему этот баг интересен:

1. Трудно найти — проявляется при очень конкретных условиях
2. Серьёзный импакт — финансовые потери
3. Требует понимания — race conditions, транзакции, locks
4. Классический паттерн — встречается в многих приложениях
5. Хороший урок — важность тестирования конкурентности

Как я тестирую такие баги

Тестирую конкурентность с использованием threading и concurrent.futures, проверяю что система остаётся в консистентном состоянии при параллельных операциях.

Этот баг научил меня всегда думать о race conditions и edge cases, требующих специальной подготовки для воспроизведения.