HISTORY: Q&A Соннета по тестам + план диагностики платформы

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

@@ -608,3 +608,37 @@ DNS ВМ. Проверки ВМ: resolv.conf = один `8.8.8.8`; dig 20/20 о
 
 **Финальный 30-мин прогон**: запущен 18:30:52 +03 (ВМ) — в процессе.
 
+## Q&A Соннета — какие ещё тесты провести (14.08.2026)
+
+**Вопрос (кратко)**: достаточен ли набор проверок; какие сценарии не покрыты; норма ли
+ReadTimeout 0.04%; серверные таймауты; нужен ли CLI v2 в нагрузке; что ещё до релиза.
+
+**Ответ Соннета (ключевое)**:
+- Не покрыто, но критично: рестарт пода с in-flight сообщениями (asyncWrite до смерти пода
+  → двойная доставка); unbounded goroutines при деградации Redis (OOM на 512Mi);
+  long-poll goroutine leak; FIFO-порядок под конкурентными receive; DLQ e2e; dedup-окно e2e.
+- Восстановление очередей из Redis после рестарта — обязательный тест.
+- ReadTimeout 0.042% — граница, снижать до <0.01%: проверить кластеризацию ошибок во времени
+  (lock contention vs gateway), keep-alive/RST на шлюзе, TCP retransmits пода.
+- Серверные таймауты добавить: ReadHeaderTimeout 10s, WriteTimeout 35s (20с long-poll + буфер),
+  IdleTimeout 90s, MaxHeaderBytes 8192. ReadTimeout НЕ ставить (рвёт long-poll).
+- AWS CLI v2 (query-mode JSON) в нагрузке — обязательно, другой путь сериализации.
+- Память (RSS 2+ часа), billing-счётчики, JWT-истечение mid-request, лимит 50 очередей
+  (граница включительно), /metrics корректность после прогона.
+- Приоритеты: P0 серверные таймауты + рестарт с in-flight; P1 Redis chaos + long-poll leak;
+  P2 CLI v2 нагрузка + FIFO dedup/DLQ e2e; P3 RSS.
+
+## План диагностики САМОЙ платформы (HTTP контейнер), независимо от SQS (14.08.2026)
+
+Пользователь: проверить, как HTTP-контейнер платформы сбоит сам по себе (аналогия:
+managed flask/nodejs/lucee не пропускают большие файлы с локали). Отделяем транспорт от логики SQS.
+
+A. Через /health (минимум логики): burst 500 параллельных; большие заголовки 8–16KB;
+   медленный запрос (1 байт/с); keep-alive 50 запросов на одном соединении; HTTP/1.0, HEAD, POST.
+B. Через SQS API, смотрим транспорт: SendMessage 256KB (с ВМ И с локальной машины);
+   chunked-тело; Receive 10×256KB (~2.5MB ответ); long-poll 20с (локаль vs ВМ).
+C. Известные аномалии: GET /ui через ingress висит ~150с (внутри пода мгновенно);
+   ReadTimeout-кластеры; max latency 52с.
+D. TCP: retransmit-счётчики пода (/proc/net/snmp) до/после.
+Итог: таблица «локаль vs ВМ vs внутри пода» — что режет платформа, а что сервис.
+