Промпт: найти причину ошибки по стектрейсу и логам

GigaChat 2 Max06.10.2026

Анализ проблемы

Наиболее вероятно, ошибка вызвана увеличением количества одновременных транзакций в БД PostgreSQL, что привело к превышению лимита ожидания соединений («idle-in-transaction timeout»). Когда один воркер удерживает соединение долго (например, ожидает ответа внешнего сервиса OFD через requests), другие воркеры ожидают освобождения соединения и время от времени получают исключение, когда сервер закрывает неактивное подключение по таймауту (EOF detected). Это видно по сообщениям в стектрейсе:

> Log Indicators
> — OperationalError('SSL SYSCALL error: EOF detected'): Подключение закрыто базой данных вследствие таймаута неактивности.
> — FATAL: terminating connection due to idle-in-transaction timeout: Прямо указывает на превышение максимального времени нахождения транзакции в ожидании.

Дополнительные гипотезы (по убыванию вероятности)

Гипотеза №1: Проблема с таймаутом подключения к внешней службе OFD

Может оказаться, что сервис OFD стал медленнее отвечать или вовсе зависает периодически, вызывая блокировку транзакций.

Проверка: Временно увеличить таймаут запроса в вызове requests.post() до значения заведомо большего, чем время выполнения типичной задачи, чтобы убедиться, проблема именно во внешних задержках.

resp = requests.post(OFD_URL, json=build_receipt(order), timeout=120)

Затем мониторьте приложение и проверьте, исчезнет ли ошибка.

Гипотеза №2: Некорректная конфигурация пула соединений Postgresql

Увеличение воркеров могло привести к исчерпанию ресурсов соединений между приложением и базой данных.

Проверка:
Проверьте состояние пулов соединений в приложении (например, используя встроенные инструменты мониторинга производительности PostgreSQL):

SELECT * FROM pg_stat_activity WHERE state='idle in transaction';

Также убедитесь, что параметр конфигурации max_connections в настройках PostgreSQL соответствует количеству одновременно ожидающих соединений. Например, установить:

echo "max_connections = 100" >> /etc/postgresql/16/main/postgresql.conf && systemctl restart postgresql

Гипотеза №3: Перегрузка сервера Redis

Redis используется Celery как брокер сообщений. Если нагрузка возросла резко, возможно, некоторые очереди начинают накапливать большое количество невыполненных задач.

Проверка: Мониторинг нагрузки Redis:

redis-cli info | grep used_memory_human

Либо посмотреть длину очередей в redis:

redis-cli llen celery

И сравнить значение с количеством активных задач в вашем окружении.

Коррекция кода

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

Пример исправления:

import asyncio
from aiohttp import ClientSession

async def async_send_receipt(session, url, data):
    try:
        async with session.post(url, json=data, timeout=60) as response:
            return await response.json()
    except Exception as e:
        print(f'Async request failed: {str(e)}')
        raise

@shared_task(bind=True, max_retries=3)
def send_receipt(self, order_id):
    loop = asyncio.get_event_loop()
    session = ClientSession()
    
    # Получаем объект заказа внутри транзакции
    with transaction.atomic():
        order = Order.objects.select_for_update().get(pk=order_id)
        
        # Выполняем внешний запрос асинхронно вне транзакции
        result = loop.run_until_complete(async_send_receipt(session, OFD_URL, build_receipt(order)))
        if isinstance(result, dict) and 'status' in result:
            order.receipt_status = result['status']
            order.save()
        else:
            self.retry(countdown=60*5)  # Повтор через 5 минут
            
    session.close()

Здесь мы используем модуль asyncio, который позволяет отделять выполнение запросов от базы данных и обработки заказов. Таким образом, база данных освобождается быстрее, уменьшая вероятность получения исключений связанных с временем ожидания.

Профилактика повторного появления ошибки

1. Тестирование: Написание интеграционного теста с нагрузкой, имитирующей многопоточность выполнения запросов, проверяя устойчивость приложения при увеличенном количестве воркеров и задержке работы внешних служб.

``python
@pytest.mark.django_db(transaction=True)
def test_celery_tasks_under_load(client, settings):
for _ in range(10): # Запуск нескольких параллельных задач
send_receipt.delay(randint(1, 10))
time.sleep(60) # Ждём завершения всех задач
assert not Order.objects.filter(receipt_status=None).exists(), "Не все чеки отправлены"
``

1. Метрики: Добавляем мониторинг продолжительности транзакций и отслеживание состояния Redis и PostgreSQL с помощью инструментов вроде Prometheus + Grafana.

1. Алерты: Настроить оповещения при достижении критического уровня занятости подключений к PostgreSQL и длин очередей Redis.

Используя эти меры, можно существенно снизить риск возникновения аналогичных проблем в будущем.

ChatGPT (GPT-5.5)06.10.2026

1. Наиболее вероятная причина

С высокой вероятностью задача держит открытую PostgreSQL-транзакцию во время внешнего HTTP-запроса в ОФД:

with transaction.atomic():
    order = Order.objects.select_for_update().get(pk=order_id)
    resp = requests.post(OFD_URL, json=build_receipt(order), timeout=60)
    order.receipt_status = resp.json()["status"]
    order.save()

Для PostgreSQL это выглядит как сессия в состоянии idle in transaction: транзакция открыта, lock на строке взят, но SQL-запросов долго нет, потому что процесс ждёт ответ от requests.post(...). PostgreSQL убивает такую сессию по idle_in_transaction_session_timeout, после чего Django получает разорванное соединение:

OperationalError('SSL SYSCALL error: EOF detected')

На это прямо указывают строки:

django.db.utils.OperationalError: SSL SYSCALL error: EOF detected
postgres: FATAL: terminating connection due to idle-in-transaction timeout

То, что проблема началась после увеличения Celery workers с 2 до 8, тоже укладывается: стало больше параллельных задач, больше долгих открытых транзакций, больше блокировок и больше шансов попасть в timeout.

2. Другие гипотезы по убыванию вероятности и как проверить

Гипотеза A — HTTP-запрос в ОФД иногда занимает слишком долго

Даже при timeout=60 задача может держать транзакцию десятки секунд. Если в PostgreSQL idle_in_transaction_session_timeout, например, 30 секунд, соединение будет убито.

Проверить timeout в PostgreSQL:

SHOW idle_in_transaction_session_timeout;

Посмотреть активные/зависшие транзакции:

SELECT
    pid,
    usename,
    application_name,
    client_addr,
    state,
    now() - xact_start AS xact_age,
    now() - state_change AS state_age,
    wait_event_type,
    wait_event,
    query
FROM pg_stat_activity
WHERE datname = current_database()
ORDER BY xact_start NULLS LAST;

Особенно интересны строки:

state = 'idle in transaction'
xact_age/state_age растёт
query похож на SELECT ... FOR UPDATE ...

Проверить логи приложения вокруг HTTP:

logger.info("sending receipt to OFD", extra={"order_id": order_id})
resp = requests.post(...)
logger.info("OFD responded", extra={"order_id": order_id, "status_code": resp.status_code})

Если между этими логами десятки секунд — это подтверждает причину.

Гипотеза B — блокировки из-за select_for_update() при параллельной обработке одного заказа

Если несколько задач одновременно пытаются отправить чек по одному и тому же order_id, одна задача держит lock, остальные ждут на select_for_update().

Проверить блокировки:

SELECT
    blocked.pid AS blocked_pid,
    blocked.query AS blocked_query,
    blocking.pid AS blocking_pid,
    blocking.query AS blocking_query,
    now() - blocking.xact_start AS blocking_xact_age
FROM pg_stat_activity blocked
JOIN pg_locks blocked_locks
    ON blocked_locks.pid = blocked.pid
JOIN pg_locks blocking_locks
    ON blocking_locks.locktype = blocked_locks.locktype
   AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database
   AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
   AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
   AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
   AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
   AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
   AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
   AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
   AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
   AND blocking_locks.pid != blocked_locks.pid
JOIN pg_stat_activity blocking
    ON blocking.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted;

Быстрая проверка по логам Celery: посмотрите, не запускается ли одновременно несколько задач с одним order_id.

Добавить лог в начало задачи:

logger.info("send_receipt started", extra={"order_id": order_id, "task_id": self.request.id})

Гипотеза C — исчерпание лимита соединений PostgreSQL после увеличения workers

Celery prefork с 8 воркерами может создавать больше процессов и, соответственно, больше DB-соединений. Если есть несколько контейнеров Celery, web-процессы, beat и т.д., можно приблизиться к max_connections.

Проверить:

SHOW max_connections;

SELECT
    count(*) AS total_connections,
    count(*) FILTER (WHERE state = 'active') AS active,
    count(*) FILTER (WHERE state = 'idle') AS idle,
    count(*) FILTER (WHERE state = 'idle in transaction') AS idle_in_transaction
FROM pg_stat_activity
WHERE datname = current_database();

По приложениям:

SELECT
    application_name,
    state,
    count(*)
FROM pg_stat_activity
WHERE datname = current_database()
GROUP BY application_name, state
ORDER BY count(*) DESC;

В логах PostgreSQL при этой проблеме обычно были бы сообщения вроде:

FATAL: sorry, too many clients already

В вашем фрагменте их нет, поэтому это менее вероятно, чем idle-in-transaction.

Гипотеза D — сетевой разрыв между контейнером приложения и PostgreSQL

SSL SYSCALL error: EOF detected может быть следствием сетевого обрыва, рестарта PostgreSQL, рестарта контейнера, LB/NAT timeout и т.п.

Проверить Docker-события:

docker events --since "2026-10-05T13:50:00" --until "2026-10-05T14:10:00"

Проверить рестарты контейнеров:

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.RunningFor}}'

Логи PostgreSQL вокруг времени ошибки:

docker logs postgres_container_name --since "2026-10-05T13:50:00" --until "2026-10-05T14:10:00"

Но конкретная строка:

terminating connection due to idle-in-transaction timeout

уже объясняет разрыв соединения без привлечения сетевой проблемы.

Гипотеза E — старые/битые DB-соединения в Celery-процессах

Иногда Celery-процессы держат соединения дольше, чем ожидается, особенно при неправильной инициализации Django или кастомных настройках. Но Django обычно умеет закрывать/переоткрывать устаревшие соединения на границах задач при корректной интеграции.

Проверить настройки:

DATABASES["default"].get("CONN_MAX_AGE")

Посмотреть, не открываются ли DB-соединения до fork воркеров.

В качестве временной диагностики можно добавить в начало задачи:

from django.db import close_old_connections

@shared_task(bind=True, max_retries=3)
def send_receipt(self, order_id):
    close_old_connections()
    ...

Но это не исправляет главную проблему: внешний HTTP внутри транзакции.

3. Исправление с кодом и объяснением

Главное правило: не делать внешние сетевые вызовы внутри transaction.atomic() и под select_for_update().

Текущий код держит:

1. открытую транзакцию;
2. row-level lock на Order;
3. соединение PostgreSQL;
4. всё это на время запроса в ОФД.

Нужно разделить процесс на короткие транзакции:

1. быстро забрать заказ и пометить как sending;
2. закрыть транзакцию;
3. отправить чек в ОФД;
4. короткой транзакцией сохранить результат.

Пример:

import requests

from celery import shared_task
from django.db import transaction, OperationalError
from django.utils import timezone

from billing.models import Order


@shared_task(
    bind=True,
    max_retries=3,
    autoretry_for=(requests.RequestException, OperationalError),
    retry_backoff=True,
    retry_jitter=True,
)
def send_receipt(self, order_id):
    # 1. Короткая транзакция: забираем заказ в обработку.
    with transaction.atomic():
        order = (
            Order.objects
            .select_for_update()
            .get(pk=order_id)
        )

        if order.receipt_status in {"sent", "success"}:
            return

        if order.receipt_status == "sending":
            # Здесь зависит от вашей бизнес-логики.
            # Можно выйти, чтобы не отправить дубль.
            return

        receipt_payload = build_receipt(order)

        order.receipt_status = "sending"
        order.receipt_sending_started_at = timezone.now()
        order.save(
            update_fields=[
                "receipt_status",
                "receipt_sending_started_at",
            ]
        )

    # 2. Внешний HTTP-запрос — уже БЕЗ транзакции и БЕЗ lock.
    resp = requests.post(
        OFD_URL,
        json=receipt_payload,
        timeout=(5, 60),
    )
    resp.raise_for_status()

    data = resp.json()
    ofd_status = data["status"]

    # 3. Короткая транзакция: сохраняем результат.
    with transaction.atomic():
        order = (
            Order.objects
            .select_for_update()
            .get(pk=order_id)
        )

        order.receipt_status = ofd_status
        order.receipt_sent_at = timezone.now()
        order.save(
            update_fields=[
                "receipt_status",
                "receipt_sent_at",
            ]
        )

Важные моменты:

• requests.post(...) вынесен из transaction.atomic().
• select_for_update() используется только на коротких участках.
• Долгий внешний вызов больше не держит PostgreSQL-транзакцию.
• timeout=(5, 60) разделяет connect timeout и read timeout. Сигнатура requests поддерживает tuple (connect_timeout, read_timeout).
• resp.raise_for_status() нужен, чтобы HTTP 500/502/504 не обрабатывались как успешный ответ.
• autoretry_for добавляет ретраи на сетевые ошибки и transient DB errors.

Но здесь есть важный бизнес-нюанс: ОФД и чеки обычно требуют идемпотентности. Если задача отправила чек, но упала до сохранения результата, retry может отправить дубль. Поэтому лучше передавать в ОФД уникальный идентификатор чека/операции, если API ОФД это поддерживает.

Например:

receipt_id = str(order.receipt_uuid)

и включать его в payload:

receipt_payload = build_receipt(order)
receipt_payload["external_id"] = str(order.receipt_uuid)

Я не знаю API вашего ОФД, поэтому точное поле не называю. Нужно посмотреть документацию конкретного провайдера: обычно это что-то вроде external_id, request_id, operation_id, invoice_id.

Более строгий вариант — не использовать строковый статус sending без срока жизни, а сделать recoverable state:

if order.receipt_status == "sending":
    if order.receipt_sending_started_at and timezone.now() - order.receipt_sending_started_at < timedelta(minutes=10):
        return
    # Старая зависшая отправка — можно попробовать снова.

Пример:

from datetime import timedelta

import requests

from celery import shared_task
from django.db import transaction, OperationalError
from django.utils import timezone


@shared_task(
    bind=True,
    max_retries=3,
    autoretry_for=(requests.RequestException, OperationalError),
    retry_backoff=True,
    retry_jitter=True,
)
def send_receipt(self, order_id):
    now = timezone.now()

    with transaction.atomic():
        order = Order.objects.select_for_update().get(pk=order_id)

        if order.receipt_status in {"sent", "success"}:
            return

        if (
            order.receipt_status == "sending"
            and order.receipt_sending_started_at
            and now - order.receipt_sending_started_at < timedelta(minutes=10)
        ):
            return

        payload = build_receipt(order)

        order.receipt_status = "sending"
        order.receipt_sending_started_at = now
        order.save(
            update_fields=[
                "receipt_status",
                "receipt_sending_started_at",
            ]
        )

    response = requests.post(
        OFD_URL,
        json=payload,
        timeout=(5, 60),
    )
    response.raise_for_status()
    result = response.json()

    with transaction.atomic():
        order = Order.objects.select_for_update().get(pk=order_id)

        order.receipt_status = result["status"]
        order.receipt_sent_at = timezone.now()
        order.receipt_last_error = ""
        order.save(
            update_fields=[
                "receipt_status",
                "receipt_sent_at",
                "receipt_last_error",
            ]
        )

Если надо логировать ошибку в БД при неуспешной отправке:

@shared_task(
    bind=True,
    max_retries=3,
    autoretry_for=(requests.RequestException, OperationalError),
    retry_backoff=True,
    retry_jitter=True,
)
def send_receipt(self, order_id):
    try:
        ...
    except requests.RequestException as exc:
        with transaction.atomic():
            Order.objects.filter(pk=order_id).update(
                receipt_status="retry",
                receipt_last_error=str(exc)[:1000],
            )
        raise

Но осторожно: если autoretry_for перехватывает исключение, ваш except должен быть совместим с этой логикой. Альтернативно можно не использовать autoretry_for, а явно делать:

try:
    ...
except requests.RequestException as exc:
    raise self.retry(exc=exc)

4. Как не допустить повторения

Тест

Минимальный unit/integration test: убедиться, что HTTP-вызов не происходит внутри транзакции.

Пример с monkeypatch/mock:

from django.db import connection
from billing.tasks import send_receipt


def test_send_receipt_does_not_call_ofd_inside_transaction(db, order, monkeypatch):
    def fake_post(*args, **kwargs):
        assert connection.in_atomic_block is False
        class Response:
            def raise_for_status(self):
                pass

            def json(self):
                return {"status": "sent"}

        return Response()

    monkeypatch.setattr("billing.tasks.requests.post", fake_post)

    send_receipt(order.id)

Если задача вызывается как Celery task object, в тесте может понадобиться:

send_receipt.run(order.id)

Точная форма зависит от того, как у вас настроены Celery tasks.

Также полезен тест на конкуренцию: две параллельные попытки отправить чек для одного заказа не должны отправить два HTTP-запроса. Реализация зависит от выбранной модели статусов и идемпотентности.

Метрика

Нужны метрики по PostgreSQL:

SELECT count(*)
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND datname = current_database();

И максимальный возраст транзакции:

SELECT
    max(now() - xact_start) AS max_transaction_age
FROM pg_stat_activity
WHERE datname = current_database()
  AND xact_start IS NOT NULL;

Отдельно полезно мониторить:

• количество idle in transaction;
• максимальный xact_age;
• количество блокировок;
• количество Celery retries/failures по send_receipt;
• latency запросов в ОФД;
• количество задач в очереди;
• число активных DB connections.

Алерт

Примеры условий:

1. Есть долгие idle-in-transaction:

idle_in_transaction_count > 0 for 5 minutes

или строже:

max_idle_in_transaction_age > 30s for 2 minutes

1. Долгие транзакции:

max_transaction_age > 60s for 5 minutes

1. Рост ошибок Celery:

rate(celery_task_failed_total{task="billing.tasks.send_receipt"}[5m]) > 0

1. Рост retries:

rate(celery_task_retried_total{task="billing.tasks.send_receipt"}[5m]) > baseline

1. Долгий ОФД:

p95(ofd_request_duration_seconds) > 10s for 5 minutes

Что ещё полезно прислать для окончательной уверенности

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

1. значение:

SHOW idle_in_transaction_session_timeout;

1. модель Order, особенно поля receipt_status, уникальные идентификаторы чека/заказа;
2. допускает ли API ОФД идемпотентный ключ;
3. могут ли одновременно создаваться несколько задач send_receipt на один order_id;
4. настройки Celery:
5. concurrency;
6. prefetch multiplier;
7. acks_late;
8. retry policy;
9. настройки Django DB:
10. CONN_MAX_AGE;
11. pgbouncer есть или нет;
12. реальные длительности запросов в ОФД.

Claude Sonnet 506.10.2026

1. Наиболее вероятная причина

Транзакция transaction.atomic() держит открытой строку (select_for_update()) на всё время сетевого запроса к ОФД (до 60 сек). Пока Python ждёt ответ requests.post, PostgreSQL видит сессию как «idle in transaction» (команда уже выполнена, новой пока нет). Если это состояние превышает idle_in_transaction_session_timeout, Postgres принудительно рвёт соединение — это прямо подтверждается строкой лога:

postgres: FATAL: terminating connection due to idle-in-transaction timeout

а на стороне Celery это проявляется как OperationalError('SSL SYSCALL error: EOF detected') — клиент просто видит разорванный сокет.

Почему проявилось после роста воркеров 2→8: выросло число одновременных долгих транзакций и, вероятно, возросла нагрузка на сам ОФД (одновременные запросы могут тормозить дольше обычного) — вероятность того, что хотя бы один воркер «подвиснет» внутри транзакции дольше таймаута, резко увеличивается с конкурентностью, даже если среднее время ответа не изменилось.

2. Другие гипотезы (по убыванию вероятности)

3. Исправление

Главный принцип: никогда не делать сетевой I/O внутри открытой БД-транзакции, тем более под блокировкой строки. Разбиваем задачу на короткие транзакции:

from django.db import transaction
from django.db.utils import OperationalError
import requests

@shared_task(
    bind=True,
    max_retries=5,
    retry_backoff=True,
    retry_backoff_max=60,
    retry_jitter=True,
    autoretry_for=(OperationalError, requests.RequestException),
)
def send_receipt(self, order_id):
    # 1. Короткая транзакция: берём лок, проверяем состояние, фиксируем намерение
    with transaction.atomic():
        order = Order.objects.select_for_update(skip_locked=True).get(pk=order_id)
        if order.receipt_status in ("sent", "sending"):
            return  # защита от дублей при конкурентных ретраях
        order.receipt_status = "sending"
        order.save(update_fields=["receipt_status"])
        payload = build_receipt(order)
    # лок уже снят здесь — сетевой вызов идёт БЕЗ удержания транзакции

    # 2. Сетевой вызов вне транзакции
    resp = requests.post(OFD_URL, json=payload, timeout=60)
    resp.raise_for_status()
    status = resp.json()["status"]

    # 3. Короткая транзакция фиксации результата
    with transaction.atomic():
        Order.objects.filter(pk=order_id).update(receipt_status=status)

Дополнительно:

• skip_locked=True — если два воркера случайно схватили одну задачу (например, из-за дублирующего retry), второй не будет висеть в ожидании лока.
• Нужна фоновая reconciliation-задача (раз в N минут), которая находит заказы, зависшие в статусе sending дольше X минут, и переводит их обратно в pending/ставит на повторную отправку — на случай падения процесса между шагом 1 и 2.
• Проверить и нормализовать CONN_MAX_AGE в DATABASES и включить CONN_HEALTH_CHECKS = True (Django ≥4.1), чтобы не переиспользовать «протухшие» соединения.
• На старте Celery worker (worker_process_init signal) явно вызывать django.db.connections.close_all(), чтобы форки не наследовали родительский сокет к Postgres.
• Добавить autoretry_for=(OperationalError,) — чтобы такие разрывы сами собой гасились ретраем без ручного вмешательства (пока правим архитектуру).

4. Как не допустить повторения

Тест:

• Юнит/интеграционный тест с моком requests.post, искусственно задерживающим ответ (time.sleep), и проверкой, что во время задержки нет открытой транзакции/лока — например, через TransactionTestCase + отдельный поток, который пытается получить тот же select_for_update и не должен блокироваться дольше X мс.
• Статическая проверка (кастомное правило flake8/bandit или code review checklist): запрещать сетевые вызовы (requests., httpx.) внутри блока with transaction.atomic():.

Метрики:

• Длительность удержания БД-транзакции в задаче (отдельный таймер вокруг atomic() блока), экспортировать в Prometheus/StatsD.
• pg_stat_activity state=idle in transaction — count и max duration (через postgres_exporter).
• Latency запросов к ОФД (p50/p95/p99), success/retry rate задачи send_receipt.

Алерты:

• Алерт на появление в логах Postgres idle-in-transaction timeout (>0 раз в интервал).
• Алерт на рост retry-rate Celery-задачи send_receipt выше baseline.
• Алерт при приближении числа соединений к Postgres к max_connections (например, >80%).

Чего не хватает для 100% уверенности (стоит прислать)

• Значение idle_in_transaction_session_timeout в Postgres (и вообще postgresql.conf/значения на RDS).
• Конфигурацию Celery: pool type (prefork/gevent), worker_concurrency, есть ли сигнал worker_process_init/close_all().
• DATABASES['default']['CONN_MAX_AGE'] и OPTIONS в settings.py.
• Наличие PgBouncer/connection pooler между Django и Postgres и его режим (session/transaction pooling).
• Типичное и максимальное время ответа OFD_URL за последние недели (до и после масштабирования).
• Полный pg_stat_activity snapshot или больше строк лога вокруг инцидента (нет ли других WARNING/ERROR рядом).

Gemini 2.5 Flash06.10.2026

Отлично, коллега. Давайте разберем эту проблему.

1. Наиболее вероятная причина

Наиболее вероятная причина - это разрыв соединения с базой данных PostgreSQL из-за таймаута бездействия транзакции, пока задача Celery ожидает ответа от внешнего сервиса (ОФД). Строки лога, указывающие на это:

• [2026-10-05 14:02:11,402: ERROR/ForkPoolWorker-6] Task billing.tasks.send_receipt[8f1c2a] raised unexpected: OperationalError('SSL SYSCALL error: EOF detected') - это ошибка, которую получил Celery-воркер от Django/PostgreSQL.
• [2026-10-05 14:02:11,950: WARNING/MainProcess] postgres: FATAL: terminating connection due to idle-in-transaction timeout - это сообщение от самого PostgreSQL, которое прямо указывает на причину разрыва соединения.

Ваша транзакция была открыта (with transaction.atomic():), затем вы получили блокировку (select_for_update()), а затем отправили HTTP-запрос к OFD_URL. Если этот запрос занимает больше времени, чем idle_in_transaction_session_timeout на сервере PostgreSQL, то PostgreSQL принудительно разорвет соединение, пока транзакция все еще открыта и ожидает. Увеличение числа воркеров Celery увеличило вероятность того, что несколько таких задач будут выполняться параллельно, создавая больше нагрузки и, возможно, увеличивая время ответа от ОФД или просто увеличивая шансы на совпадение с таймаутом.

2. Другие гипотезы по убыванию вероятности

1. Проблемы с сетью или нестабильность соединения между Celery-воркером и PostgreSQL.
2. Как проверить:
3. Логи: Просмотреть логи Docker-контейнеров Celery и PostgreSQL на предмет других ошибок сети (например, Connection refused, Host unreachable) или необычных сообщений о разрыве соединений, которые не связаны с idle-in-transaction timeout.
4. Мониторинг: Если есть система мониторинга сети, проверить графики задержек и потерь пакетов между хостами Celery и PostgreSQL.
5. Команда: Из контейнера Celery-воркера выполнить ping <postgres_host> или nc -vz <postgres_host> <postgres_port> для проверки базовой связности.

1. Перегрузка PostgreSQL-сервера.
2. Как проверить:
3. Мониторинг: Проверить метрики PostgreSQL (CPU, RAM, I/O, количество активных соединений, количество ожидающих запросов, pg_stat_activity) в моменты возникновения ошибок. Если сервер перегружен, он может медленнее обрабатывать запросы, что увеличивает вероятность таймаутов.
4. Логи PostgreSQL: Искать сообщения о медленных запросах, блокировках (кроме select_for_update на order_id), или других проблемах производительности.
5. SQL-запрос: Выполнить SELECT * FROM pg_stat_activity; во время пиковой нагрузки, чтобы увидеть, сколько соединений активно и что они делают.

1. Проблемы с пулом соединений Django/Psycopg2.
2. Как проверить:
3. Конфигурация Django: Проверить настройки CONN_MAX_AGE в DATABASES в settings.py. Если CONN_MAX_AGE установлен слишком высоко или равен 0 (постоянные соединения), а PostgreSQL разрывает их по таймауту, Django может пытаться использовать уже закрытое соединение.
4. Логи: Искать другие ошибки, связанные с пулом соединений, например, InterfaceError или DatabaseError с другими сообщениями, нежели EOF detected.
5. Точка останова: Вставить точку останова (или логирование) перед Order.objects.select_for_update().get(pk=order_id) и после requests.post(...) для проверки состояния соединения (хотя это сложно сделать напрямую с пулом соединений Django).

3. Исправление с кодом и объяснением

Наилучшее исправление в данном случае - вынести HTTP-запрос к внешнему сервису за пределы транзакции базы данных.

import requests
from django.db import transaction
from celery import shared_task
from .models import Order # Предполагаем, что Order находится в той же app
from django.conf import settings # Для OFD_URL

OFD_URL = settings.OFD_URL # Или откуда вы его берете

@shared_task(bind=True, max_retries=3)
def send_receipt(self, order_id):
    # 1. Получаем заказ и блокируем его внутри транзакции
    with transaction.atomic():
        order = Order.objects.select_for_update().get(pk=order_id)
        # Если здесь есть какая-то логика, которая должна быть атомарной с получением заказа,
        # она должна остаться внутри этой транзакции.
        # Например, проверка статуса, который может измениться.
        
        # Сохраняем необходимые данные для запроса к ОФД
        receipt_data = build_receipt(order)
        
        # Если нужно, можно сразу обновить статус, что чек отправляется,
        # чтобы избежать повторной обработки, если запрос к ОФД упадет.
        # order.receipt_status = Order.RECEIPT_STATUS_SENDING # Пример
        # order.save()
        # transaction.on_commit(lambda: None) # Гарантируем, что транзакция зафиксирована перед внешним запросом

    # 2. Выполняем HTTP-запрос вне транзакции
    try:
        resp = requests.post(OFD_URL, json=receipt_data, timeout=60)
        resp.raise_for_status() # Поднимает исключение для плохих статусов (4xx, 5xx)
        new_status = resp.json()["status"]
    except requests.exceptions.RequestException as e:
        # Обработка ошибок сети или HTTP-статусов
        # Возможно, здесь нужно повторить задачу или установить статус ошибки
        print(f"Error sending receipt for order {order_id}: {e}")
        # Если хотим повторить задачу, можно использовать self.retry()
        self.retry(exc=e, countdown=60) # Повторить через 60 секунд
        return # Выходим, чтобы не обновлять статус в БД

    # 3. Обновляем статус заказа в новой, короткой транзакции
    with transaction.atomic():
        # Важно: снова получаем заказ, так как предыдущий объект 'order' может быть устаревшим
        # или его соединение могло быть разорвано.
        # select_for_update здесь не нужен, если мы просто обновляем статус.
        # Если есть риск гонки, можно использовать F-выражения или снова select_for_update.
        order_to_update = Order.objects.get(pk=order_id)
        order_to_update.receipt_status = new_status
        order_to_update.save()

Объяснение:

• Мы разделяем операцию на две или три атомарные части:
• Получение и блокировка данных: Первая транзакция (with transaction.atomic():) используется для получения Order и, если необходимо, для выполнения других атомарных операций с базой данных. Эта транзакция будет очень короткой.
• Внешний HTTP-запрос: Запрос к OFD_URL выполняется вне активной транзакции базы данных. Это означает, что даже если запрос займет много времени (например, 60 секунд таймаута), соединение с PostgreSQL не будет удерживаться в состоянии "idle-in-transaction", и PostgreSQL не разорвет его.
• Обновление статуса: После получения ответа от ОФД, мы открываем новую, короткую транзакцию для обновления статуса заказа. Это гарантирует, что обновление статуса также будет атомарным.

Это устраняет корневую причину idle-in-transaction timeout.

4. Как не допустить повторения

1. Тест:
2. Интеграционный тест: Создать интеграционный тест для задачи send_receipt. В этом тесте можно использовать "mock" для requests.post, который будет имитировать задержку (например, time.sleep(70)), превышающую idle_in_transaction_session_timeout (обычно 60 секунд по умолчанию в PostgreSQL). Убедиться, что задача не падает с OperationalError и корректно обрабатывает результат после задержки.
3. Unit-тест: Убедиться, что build_receipt работает корректно и что логика обновления статуса после получения ответа от ОФД также корректна.

1. Метрика:
2. Время выполнения внешних запросов: Добавить метрики (например, с помощью Prometheus/Grafana или Sentry) для отслеживания времени выполнения запросов к OFD_URL. Если среднее или P95/P99 время ответа начинает расти, это может указывать на потенциальные проблемы с ОФД или сетью.
3. Количество задач в состоянии "pending" или "retrying": Мониторинг очереди Celery. Резкое увеличение числа ожидающих или повторяющихся задач может быть признаком проблемы.
4. Количество idle-in-transaction соединений: Мониторинг метрики pg_stat_activity в PostgreSQL, чтобы отслеживать количество соединений в состоянии idle in transaction. Если это число растет, это может указывать на другие места в коде, где транзакции удерживаются слишком долго.

1. Алерт:
2. Алерт на OperationalError: Настроить алерт в системе мониторинга (Sentry, Grafana Alerts, Prometheus Alertmanager) на появление django.db.utils.OperationalError или конкретно SSL SYSCALL error: EOF detected в логах Celery-воркеров.
3. Алерт на idle-in-transaction timeout в логах PostgreSQL: Настроить алерт на появление сообщения FATAL: terminating connection due to idle-in-transaction timeout в логах PostgreSQL.
4. Алерт на время ответа ОФД: Если время ответа от OFD_URL превышает определенный порог (например, 30 секунд), это может быть сигналом о проблеме, которая потенциально приведет к таймаутам.
5. Алерт на количество повторяющихся задач: Если задача send_receipt начинает слишком часто повторяться (например, более 5% от всех вызовов за час), это может указывать на проблему.

Это комплексный подход, который должен помочь решить текущую проблему и предотвратить ее повторение в будущем.