Describe atomic REQUEST acceptance and committed acknowledgment tests

doc/encrypted_attachments.md

@@ -136,12 +136,17 @@ REQUEST=1, REQUEST_ACK=2, GRANT=3, DENY=4, RESULT_ACK=5
 ответ только от автора, по своему существующему запросу и точной идентичности
 контейнера. Конфликтующие ключи и результаты отклоняются.
 
-Приём REQUEST пока использует SAVEPOINT: REQUEST_ACK и событие следуют после RELEASE.
-Без внешней транзакции это фиксирует запрос. Внутри внешней транзакции подтверждение
-может уйти до commit: последующий rollback удаляет запрос у автора, а получатель уже
-перешёл в state=1 и удалил REQUEST из outbox. Ожидание сохраняется после restart автора
-при живых маршрутах. Этот отдельный дефект приёма ещё не исправлен;
-доказательства — [chat_audit_findings.txt](chat_audit_findings.txt), «Аудит приёма REQUEST».
+Приём REQUEST использует собственную BEGIN IMMEDIATE/COMMIT. Внешняя транзакция
+отклоняется без изменений до чтения идентичности/прав. Под блокировкой проверяются
+UUID/hash контейнера, допуск участника и авторство, затем читается существующий запрос.
+Отсутствующий запрос вставляется со state=0 и проверкой одной строки; дубликат сохраняет
+решение и created_at. Только incoming=1 и state=0/2/3/4 допустимы:0 ожидает автора,
+2/4 повторяют GRANT в outbox,3 повторяет DENY. Все SQL-этапы проверяются; ACK/событие
+отправляются после commit. При отказе прежние запрос/очередь сохраняются, ACK не отправляется.
+Если после commit ACK не доставлен, клиент повторяет REQUEST; сохранённый запрос
+позволяет повторно подтвердить приём и прежнее решение. Неудачный rollback с открытой
+транзакцией требует quiesce/stop и закрытия ядра владельцем после poll.
+История дефекта и исправления — [chat_audit_findings.txt](chat_audit_findings.txt).
 
 GRANT/DENY появляются
 в outbox в одной собственной BEGIN IMMEDIATE/COMMIT с решением автора. Проверка прав
@@ -196,6 +201,15 @@ backpressure и повтором через 5 секунд; restart продол
 Дополнительно проверяются настоящий commit veto, INSERT ABORT/IGNORE, внешняя транзакция,
 синхронный отказ запуска, restart с опубликованным ключом и отказ rollback с закрытием БД владельцем.
 
+`test_attachment_requests` проверяет247 SQL-отказов/повторов новой записи и дубликатов
+0/2/3/4, с пустой/существующей очередью. Подписанный мембер и сообщение создаются
+штатными API, локальная запись вложения — фикстурой. Readonly reader в точке ACK
+и события проверяет committed key/error/request/state/date/command/retry и соседний ключ.
+Дополнительно: ABORT/IGNORE при INSERT запроса и INSERT/UPDATE outbox, настоящий commit veto,
+внешняя транзакция, неверные состояние/направление/идентичность/флаги/мембер,
+потеря ACK из-за маршрута/backpressure/send failure и повтор с прежней датой,
+отказ rollback с остановкой и закрытием БД владельцем.
+
 `test_attachment_decisions` проверяет116 SQL-отказов/повторов выдачи и отказа, с пустой
 и существующей очередью: чтение подписанного мембера, допуск автора, запись состояния,
 outbox, BEGIN/COMMIT. Участник имеет настоящие join/invitation подписи, сообщение
@@ -209,6 +223,10 @@ UPDATE состояния и INSERT/UPDATE очереди, внешняя тра
 перезапуски автора с запросами и получателя с ключом, выдача B и отказ C,
 отсутствие ключа на S/C, отрицательные control-пакеты, повтор GRANT,
 восстановление удалённого plaintext без нового согласия и удаление канала.
+На Linux первый настоящий REQUEST от B обрабатывается внутри внешней транзакции:
+проверяются её сохранность, отсутствие ACK/события/авторской записи и сохранение очереди B.
+После rollback владельцем и restart автора настоящий повтор REQUEST принимается;
+readonly reader видит сохранённый pending-запрос до отправки реального REQUEST_ACK.
 На Linux пропуск GRANT outbox и внешняя транзакция автора отвергаются без изменения
 ожидающего запроса и без события. После restart автора повтор решения сохраняет
 state+outbox; отдельное readonly-соединение подтверждает их в момент единственного события UI.

doc/service_lifecycle.md

@@ -37,7 +37,7 @@ Desktop и Android проверяют `instance->running` вместе со св
 включая Android-цикл после restart. Запрос из callback завершает цикл после возврата
 из текущего poll; уже начатая обработка остальных callbacks этого poll не прерывается.
 Владелец затем снимает media-привязки, уничтожает ядро и освобождает uasync.
-Это используется также при отказе rollback подготовки вложения, решения автора или применения ответа о ключе, если SQL-транзакция
+Это используется также при отказе rollback подготовки вложения, приёма REQUEST, решения автора или ответа о ключе, если SQL-транзакция
 осталась открыта: модуль вложений предварительно прекращает приём и снимает свой таймер/router.
 
 Create уже подготавливает listeners, топологию/SQLite, router/proxy и мониторинг;