arm-tabular-parser/spec.md at 46ef814b10fcce9ee279747aad6b6669a3bcb1ab

Andrey Epifancev 817487b976 nats: subject'ы как в старом АРМ — files.*_uploaded, files.tabular_parsed (#28 )

Решение владельца 08.10.2026: recognition.tabular.request → files.tabular_uploaded,
recognition.image.request → files.img_uploaded, recognition.result →
files.tabular_parsed (общий subject ack и результатов; files.img_parsed не
используется). Тела сообщений, Nats-Msg-Id, queue group'ы и schema_version не
меняются. Константы api/src/contract/subjects.py, докстринги, тесты, README,
CLAUDE.md; копии схем api/contracts/ из docs/contracts/ побайтно; change
nats-files-subjects с дельтой спеки. Сквозной change — RSHB/arm-ka-docs#74.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012vJkmBGKKqMoEMzvsXG3y2

2026-10-08 23:46:19 +04:00

3.9 KiB

Raw Blame History

MODIFIED Requirements

Requirement: Подтверждение запроса до обработки

Сервис SHALL быть подписан на files.tabular_uploaded в queue group tabular-parser. Получив запрос, проходящий recognition-request.schema.json, сервис SHALL до чтения файла из S3 опубликовать в files.tabular_parsed конверт status = processing с job_id, file_id, service {name: "tabular-parser", version} и заголовком Nats-Msg-Id = ack:<job_id>:<attempt>. Повторный запрос с job_id, который уже обрабатывается или обработан этим процессом, SHALL получить повторный ack и MUST NOT обрабатываться второй раз.

Scenario: Ack раньше результата

WHEN опубликован запрос из docs/contracts/examples/request-tabular.json
THEN первым сообщением сервиса в files.tabular_parsed является конверт processing, и только затем — результат

Scenario: Повторный запрос во время обработки

WHEN тот же запрос доставлен второй раз, пока первый обрабатывается
THEN публикуется второй ack processing, файл из S3 повторно не читается, результат публикуется один раз

Requirement: Результат по контракту

После подтверждения сервис SHALL прочитать объект s3.key из бакета s3.bucket, вызвать парсер, записать файл результата (по recognition-result.schema.json) в results/{file_id}/{job_id}/result.json и опубликовать конверт результата (по recognition-result-message.schema.json) с заголовком Nats-Msg-Id = result:<job_id>:<attempt>. При неудаче публикации сервис SHALL повторить её до трёх раз с паузой, затем залогировать ошибку.

Scenario: Запрос с заглушкой парсера (Срез 0)

WHEN воркеру явно передана заглушка NullParser (только тесты воркера; реализация по умолчанию — реальный парсер), запрос подтверждён и объект существует в uploads/
THEN в files.tabular_parsed появляется конверт status = error, error.code = NOT_IMPLEMENTED, job_id/file_id из запроса, metrics.duration_ms ≥ 0; файл результата может отсутствовать

Scenario: Запрос с реальным парсером

WHEN запрос подтверждён и объект в uploads/ существует, но не является книгой Excel (сигнатура не XLS/XLSX/XLSB)
THEN в files.tabular_parsed появляется конверт status = error, error.code = UNSUPPORTED_FORMAT (повреждённая книга — UNREADABLE), job_id/file_id из запроса, metrics.duration_ms ≥ 0; файл результата может отсутствовать; корректная ОСВ в том же потоке даёт done (см. «Парсер — заменяемый интерфейс»)

Scenario: Повтор публикации

WHEN первая публикация конверта результата завершается ошибкой соединения, вторая — успешно
THEN конверт опубликован один раз с тем же Nats-Msg-Id, обработка не повторяется

3.9 KiB Raw Blame History Unescape Escape