HISTORY: полная регрессия на ВМ — api_test 22/22, sdk_test 15/15; флап fifo_dlq_probe разобран (гонка теста, сервис 5/5)

HISTORY/2026-08-14-session-log.md

@@ -856,3 +856,32 @@ SIGKILL/рестарте пода запись не успевает → оче
 - nohup на ВМ: каждые 60с пишет VmRSS/Threads в `rss_monitor.log` (125 сэмплов).
 - Стартовый сэмпл 08:16 +0300: VmRSS=16588 kB, Threads=13.
 - Результат — после завершения мониторинга.
+
+## 2026-08-15 (вечер) — финальная полная регрессия на ВМ + флап fifo_dlq_probe
+
+**Запуск**: всё на ВМ (пользователь оффлайн), `tests/run_full_regression.sh`
+в nohup → `full_regression.log`. Длительность 24с.
+
+**Результаты**:
+- api_test.sh: **22/22** (PASS=22 FAIL=0)
+- sdk_test.py: **15/15** (PASS=15 FAIL=0)
+- fifo_dlq_probe.py: **флап** — 3 прогона: PASS / FAIL / PASS (dlq: count=0).
+
+**Разбор флапа dlq (сервис корректен, гонка в тесте)**:
+- Механика сервиса: возврат видимости и перенос в DLQ делает тик PeriodicTasks
+  (период 1с) при истечении VisibilityTimeout. Перенос — при Retry >= MaxReceiveCount.
+- Тест: VisibilityTimeout=1с, sleep 1.5с между receive, после 3-й попытки
+  СРАЗУ drain(dlq). При рассинхроне фазы тика (attempt 2 empty — тик не успел
+  вернуть сообщение за 1.5с) вторая доставка случается в attempt 3, и проверка
+  DLQ выполняется до тика переноса → dlq пуст → FAIL. Через ~2с сообщение
+  всё равно ушло бы в DLQ.
+- Доказательство: `tests/dlq_deterministic_probe.py` — тот же сценарий, но с
+  ожиданием 2.5с после каждой доставки: **5/5 PASS**
+  (r1=1 r2=1 r3=0 dlq=1 main_left=0 во всех 5 прогонах).
+- Вывод: перенос в DLQ работает стабильно; флап — исключительно тайминг теста.
+
+**Предложенная правка** `tests/fifo_dlq_probe.py` (жду «делай»): после цикла
+попыток — опрос DLQ до 10с (drain каждые 1с) вместо мгновенного drain.
+
+**RSS-мониторинг P3.7**: продолжает писаться в `rss_monitor.log` (старт
+08:16 +0300, VmRSS=16588 kB, Threads=13).