av
63bffe2865
- Очередью служит сама таблица: доставка ждёт свёртки в статусе `pending`, канал несёт только бит «есть работа». Переполнять нечего, падение процесса очередь не теряет, а подбор `pending` при старте — обычный проход воркера, а не отдельный код. Классификация исхода общая с пересборкой журнала. - Исход разбора начал отражать доставку, а не обстоятельства: отмена и занятость базы статус не меняют (иначе конкуренция за базу выводила бы доставку из очереди навсегда), паника свёртки больше не валит процесс, а учёт доставки идёт через транзакцию с повторами. - Длинный бюджет ответа выдан маршруту приёма, а не всему серверу: `write_timeout` в Go покрывает и чтение тела, и общий подъём снял бы защиту с остальных маршрутов.
1.1 KiB
1.1 KiB
MODIFIED Requirements
Requirement: Разбор не влияет на код ответа приёма
Система MUST сохранять правило «сохранили — значит приняли»: исход разбора не меняет код ответа на доставку.
Разбор идёт после ответа, поэтому исход виден не в ответе и не в момент
ответа, а асинхронно — в delivery.parse_status и в записи лога. Когда именно
отдаётся ответ и кто сворачивает принятое, определяет capability ingest;
здесь нормируется только то, что от разбора код ответа не зависит.
Scenario: Содержимое не разобралось
- WHEN тело сохранено в архив, но разбор его содержимого не удался
- THEN ответ на приём остаётся
200 - AND исход виден в
delivery.parse_statusи в записи лога