беклог: цена читающего маршрута решена чекпойнтом и ETag, задача встаёт перед Read API

This commit is contained in:
av
2026-08-02 19:27:03 +03:00
parent 03edf1087d
commit 28d974e45d
2 changed files with 17 additions and 2 deletions
+1 -1
View File
@@ -19,9 +19,9 @@
## блокеры
- [Тай-брейк при равной полноте точек](taj-brejk-pri-ravnoj-polnote.md) — Сегодняшний порядок канонических форм берёт меньшее значение в 96% случаев — для накопительных это систематический недосчёт
- [Цена первого читающего маршрута: память, WAL и повторный опрос](cena-chitayushchego-marshruta.md) — Один запрос каталога способен выесть память процесса и раздуть WAL — а OOM здесь стоит доставок, которых телефон не перешлёт
## высокий
- [Цена первого читающего маршрута: память, WAL и повторный опрос](cena-chitayushchego-marshruta.md) — Решено: чекпойнт по таймеру плюс ETag по data_version. Берётся перед Read API — тот строится поверх этой машинерии
- [Read API: точки, выбор слоя, свёртка по сетке](read-api-tochki.md) — Данные видны только через sqlite на хосте — ни один из трёх потребителей ничего прочитать не может
- [OpenAPI-спека и Swagger UI](openapi-swagger.md) — Потребителей три и один из них агент — контракт должен читаться машиной, а не пересказываться в чате
- [MCP-сервер поверх Read API](mcp-server.md) — Агент-медик — первый заказчик проекта, а подключить его сейчас нечем
+16 -1
View File
@@ -1,6 +1,21 @@
# Цена первого читающего маршрута: память, WAL и повторный опрос
**Приоритет:** блокеры
**Приоритет:** высокий
**Решение принято 2026-08-02: вариант (г) плюс (в), именно в таком порядке.**
Разбирается без владельца: контракт хранения не меняется, данные не трогаются,
а обе части — общепринятая практика, а не собственный дизайн. Чекпойнт по
таймеру закрывает единственное проявление, которое ломает приём (диск), и стоит
одной горутины; `ETag` по `PRAGMA data_version` — один запрос к базе, снимает и
повтор, и большую часть читающих транзакций, не заводя кеша ответа.
Вариант (а) — предел и дедлайн маршрута — **не отвергнут, а отложен** до
[Read API точек](read-api-tochki.md): там предел размера ответа всё равно
проектируется, и делать его дважды не нужно. Вариант (б) не берём, пока
счётчик не заговорит. Вариант (д) — последним, если (в) окажется мало.
Задача берётся **перед** Read API: тот строится поверх этой машинерии.
Ниже — исходная постановка блокера, она же ТЗ.
## Что решить