arm-core/openspec/changes/retry-recognition-and-edit-osv-header/specs/recognition-job-exchange/spec.md

MODIFIED Requirements

Requirement: Таймаут ожидания результата

Фоновый вахтёр SHALL с периодом 30 с переводить задания processing и published с reply_deadline < now() в status = timeout, error_code = TIMEOUT, finished_at = now(), а их файлы (по current_recognition_job_id) — в stored_file.status = ERROR. Публикатор при переводе задания в dlq SHALL так же переводить файл в ERROR. Ручной повтор после TIMEOUT/NO_ACK SHALL создавать новое задание по требованию «Новая попытка обработки файла».

Scenario: Сервис взял, но не ответил

• WHEN задание в processing и reply_deadline прошёл без результата
• THEN не позднее чем через 30 с задание имеет status = timeout, файл — ERROR с error_code = TIMEOUT

ADDED Requirements

Requirement: Новая попытка обработки файла

Ручной повтор SHALL создать recognition_job с новым id, attempt = прежний attempt + 1, тем же file_id, pipeline и max_attempts, статусом queued. Предыдущая запись SHALL сохраняться без изменений. Файл SHALL ссылаться на новое задание и получить UPLOADED. Ссылка S3 на исходник и consolidation_id сохраняются; новых документов, файлов и копий исходника SHALL NOT создаваться.

Scenario: Повтор после NO_ACK

• WHEN tabular-задание ОСВ РБ завершилось dlq/NO_ACK с attempt = 1
• THEN новое задание queued имеет attempt = 2, файл UPLOADED с прежним id и объектом S3, current_recognition_job_id указывает на новый id

Requirement: Изоляция новой попытки

Новое задание SHALL начинаться без ack, результата, ошибок, метрик и времён старого задания, со свежим requested_at. Публикатор SHALL вычислить новый reply_deadline и Nats-Msg-Id для нового job_id/attempt. Запоздавшие ack/результаты прежней финальной попытки MUST NOT менять файл, создавать документы или мешать обработке нового задания.

Scenario: Старый ответ

• WHEN после создания попытки 2 пришли ack и done для попытки 1 в timeout
• THEN текущее задание, статус файла и документы не меняются; ответ логируется и игнорируется

Scenario: Публикация после недоступности NATS

• WHEN ручной повтор принят, а NATS временно недоступен
• THEN задание остаётся queued; после восстановления публикуется со свежим сроком и новым Nats-Msg-Id

Requirement: Конкурентные запросы повтора

Проверка текущего задания и лимита, создание новой попытки и переключение файла SHALL быть атомарны. Два запроса к одной неуспешной попытке MUST NOT создавать два новых задания. При rollback новое задание, переключение файла и аудит SHALL откатываться вместе.

Scenario: Двойное нажатие

• WHEN два параллельных запроса повторяют attempt = 1
• THEN создан ровно один job attempt = 2; второй одиночный запрос получает 409 FILE_NOT_RETRYABLE, а пакетный отмечает файл skipped; attempt = 3 не создаётся