Reference in New Issue
Block a user
Delete Branch "feat/491-resume-stack"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Восстановление #491 в develop (осиротел при stacked-мерже)
Проблема: #518 (resume-стек, #491) стоял базой на
feat/490, а не на develop. Когда сначала смёржили #510 (feat/490 → develop), а ПОТОМ #518 (feat/491 → feat/490), контент #491 влился в веткуfeat/490, но в develop НЕ попал (develop получил старый feat/490 через #510 до того, как #518 влили в feat/490). Итог: #518 помечен merged, но 7 коммитов #491 отсутствуют в develop (проверено ancestry, не флагом).Этот PR приносит ровно те 7 уже-заапрувленных коммитов #491 в develop, линейно (feat/491 сидит прямо на контенте develop — база
6dad309bуже в develop через #510), 0 конфликтов. Это тот же код, что был заапрувлен в #518 — ре-презентация в правильную базу, не новая работа.Коммиты:
How verified
Контент идентичен заапрувленному #518.
git merge-tree feat/491↔develop= 0 конфликтов;develop..feat/491= ровно 7 коммитов #491, все линейные поверх develop. node_modules 0.Checklist
Degraded-poll рефетчил ВСЕ страницы infinite-query каждые 2.5 c с полными parts. Вводим дельта-эндпоинт «строки, изменённые после курсора»: - POST /ai-chat/messages/delta → { rows, cursor, run: {id,status}|null }. Курсор — таймстамп часов БД (now()), клиент эхом возвращает его каждый поллинг. Окно перекрытия now()−5s ловит строку, закоммиченную с updatedAt чуть раньше момента снятия предыдущего курсора на другом autocommit- соединении (одиночные UPDATE, длинных транзакций нет). Окно ГАРАНТИРУЕТ повторы → контракт: клиентский merge идемпотентен по id (mergeById). - Run-факт едет В дельте (отдельный /run-поллинг удвоил бы QPS — отвергнуто). - Все дельта-релевантные записи (message update/finalizeOwner/reconcile/sweep, run update/finalizeIfActive/markStopRequested/sweepRunning) стампуют updatedAt через SQL now(), а не app-clock new Date(): единая монотонная ось курсора, смешанные источники часов были независимым источником пропусков. - Клиент: сервис-функция getAiChatMessagesDelta + фиксация контракта идемпотентности mergeById тестом (свап degraded-поллинга на дельту — в коммите 3, вместе с re-seed-путём attach). Тесты (observable-property на живом Postgres, не моки): - дельта-семантика + монотонность курсора; - RACE «коммит позже с updatedAt раньше курсора» — ловится окном перекрытия (наивный updatedAt > cursor пропустил бы); - окно гарантирует повторы → идемпотентный merge; - updatedAt стампуется часами БД, а не app-clock (фейк системных часов в 2099 — стамп остаётся на времени БД); - контроллер: owner-gate, форма ответа, run-факт только {id,status}. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>Персист отставал от live-стрима на целый текущий шаг, а run.stepCount как источник границы шага НЕгоден: recordStep — fire-and-forget, не атомарен с записью parts (рассинхрон сид↔маркер). Пишем маркер ТЕМ ЖЕ flush'ем, что и parts: - flushAssistant стампует metadata.stepsPersisted = число ЗАВЕРШЁННЫХ шагов, чьи parts лежат в ЭТОЙ строке (оба выводятся из finished → маркер не может разойтись с persisted parts). In-progress хвост (частичный шаг при error/abort или mid-stream flush) НЕ считается. Это step-alignment якорь, на котором строится resume-стек (ротация кольца по подтверждённому шагу N — коммит 3; attach режет хвост по «шаг > N»). - Контракт AiChatRunService.reconstructRunParts(runId) → { parts, stepsPersisted } — единственный интерфейс чтения ЖИВОГО рана (run → assistantMessageId → строка → чистый reconstructPartsFromRow). null при отсутствии рана / связанной строки / удалённой строки; маркер 0 у pre-#491 строки — безопасный пол. Потребители: attach (коммит 3), дельта (rows уже несут маркер в metadata), экспорт. messageRepo — опциональный 3-й параметр конструктора (2-арг тест-конструкции компилируются без изменений). - /messages и дельта отдают маркер в row автоматически (он внутри metadata). Тесты: property «stepsPersisted == число завершённых шагов для любого N + parts согласованы»; частичный хвост не инкрементит маркер; reconstructPartsFromRow (маркер, дефолт 0, фолбэк на content); reconstructRunParts (резолв + null-кейсы). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>Реестр ран-стримов больше не буферизует до 32МБ сырых SSE-кадров на активный ран и не выливает весь буфер в сокет синхронно при attach — это давало OOM на 1ГБ-контейнере при нескольких марафонских ранах. Теперь кольцо ограничено (env-настраиваемо, по умолчанию 4МБ) и держится в границах за счёт ротации по шагам. Серверная часть (суть коммита): - Штамповка кадров по шагам в ingestFrame. Штамп кадра = число `finish-step` кадров ДО него (с 0); сам finish-step несёт текущее значение, затем счётчик инкрементится. Так штамп совпадает с `metadata.stepsPersisted`: клиент с N персистнутыми шагами имеет 0..N-1 в сиде и просит хвост `stamp >= N`. Границу ловим дешёвым startsWith по `data: {"type":"finish-step"` — форма кадра проверена эмпирически против ai@6.0.207 (одна часть на кадр, type всегда первый ключ; кавычки в text-delta экранированы, ложных срабатываний нет). - Кольцо ротируется ТОЛЬКО на подтверждённом персисте шага N (`confirmPersistedStep`), сбрасывая кадры `stamp < N` (эти шаги уже на диске и придут в свежем сиде). `updateStreaming` теперь СИГНАЛИЗИРУЕТ исход (число персистнутых шагов или null), и ротация вызывается лишь при не-null возврате — провал персиста ничего не ротирует, кольцо покрывает БОЛЬШЕ (анти-инверсия: наивная ротация в .then() после НЕзаписанного шага дырявила бы гарантию). - Переполнение кольца сверх байтового капа вытесняет старейшие кадры; вытеснение ещё-не-персистнутого кадра открывает GAP. Гэп НЕ липкий: floor покрытия считается из кольца, поздний персист, проротировав дырявые шаги, его чистит. - attach(chatId, anchor, n): маркер шага N приходит ТОЛЬКО от клиента (сервер не читает строку — N из устаревшего сида дал бы тихую дыру в один шаг). Покрытие ОК ⟺ coverageFloor <= n; иначе 204 → клиент рефетчит (больший N) и переподключается. Хвост = синтетический `start`-кадр (ран-факт runId/chatId) + кадры `stamp >= n`. Инвариант 6 (нет кросс-ран реплея) сохранён через anchor; инвариант 4 (снапшот+регистрация в один синхронный тик) сохранён. N-срез применяется во ВСЕХ ветках, включая finished-retained: finished + N=N_final → пустой хвост + finish-кадр, клиент закрывает стрим. - Контроллер пишет хвост чанками с учётом drain (writeTailRespectingDrain), а не синхронным залпом (вторая половина OOM). Кап подписчика — производное 2× кап кольца, обе величины env-резолвятся на инстансе. Клиент: в тип строки добавлен `metadata.stepsPersisted` (источник N). PIN-SPEC трип-вайр на ai@6.0.207: `readUIMessageStream({ message })` продолжает последнее сообщение, `start`-кадр не сбрасывает parts, текст не пересекает finish-step — на этом держится продолжение при attach; апгрейд ai теперь падает громко. Тесты (observable-property против РЕАЛЬНОГО реестра/БД): детектор границы на реальной форме кадра, N-срез (в т.ч. посреди шага), ротация только на подтверждённом персисте, «персист провалился но кольцо влезло → attach успешен / провал + переполнение → 204», «устаревший N → 204 → после рефетча успех», очистка гэпа поздним персистом, finished-retained + N_final, memory-bound (5 параллельных марафонов сверх 32МБ, каждое кольцо ≤ кап). Обновлены registry/controller specs и DB-backed интеграционный attach-spec под новую сигнатуру/семантику. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>Внутреннее ре-ревью: DB-backed delta-spec молча СКИПАЛСЯ — нулевое покрытие инварианта DB-clock курсора. - Импорт `import postgres from 'postgres'` (default) при tsconfig module:commonjs без esModuleInterop компилился в `postgres_1.default(...)`, а CJS-`postgres` не имеет `.default` → TypeError в beforeAll → пустой catch → reachable=false → все 6 тестов уходили в console.warn('SKIP') и return БЕЗ ассертов (suite оставался бы зелёным даже при регрессии на new Date()). Фикс: `import * as postgres from 'postgres'` (как в рабочем int-харнессе). - Хардненг харнесса: реальная ошибка программирования в beforeAll больше НЕ маскируется под «DB unreachable» — скип легитимен только для сетевого отказа (ECONNREFUSED и т.п.), иначе rethrow → suite падает громко. - Два DB-clock теста использовали jest.useFakeTimers() целиком, что замораживало внутренние таймеры postgres.js → awaited DB round-trip зависал на 5s-капе (и вешал afterAll). Фейкаем ТОЛЬКО Date (doNotFake всех таймеров) — запрос резолвится, а инвариант «стамп от часов БД, не app-clock» по-прежнему доказан (скос процесс-часов в 2099 → стамп остаётся на времени БД). Теперь все 6 тестов РЕАЛЬНО исполняются и зелёные против живого Postgres. Два дешёвых hardening из ревью: - registry coverageFloor: пустая ветка возвращает max(currentStamp, persistedFloor) — инвариант «клиент с n=persistedFloor всегда покрыт» структурный, а не тайминг-зависимый. - GetChatDeltaDto.cursor: @IsString → @IsISO8601 — битый курсор отсекается 400 на уровне DTO, а не 500 на `::timestamptz`. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>Переводит клиент на серверный tail-only контракт resume (задел commit 3), не трогая FSM run-fsm.ts — меняется только рантайм-обвязка в chat-thread.tsx. A. Убран STRIP-механизм. Seed теперь содержит ВСЕ персистнутые строки без изъятия хвоста (стриминговый хвост — это шаги 0..N-1, к которым SDK- продолжение дописывает tail). stripRef/strippedRowRef заменены на anchorRef { id, stepsPersisted } — персистнутая assistant-строка, питающая ?anchor=<id>&n=<stepsPersisted>. Восстановления stripped-строки на 204/NONE/starved удалены (строку никто не изымал — нечего восстанавливать); invalidateQueries + диспатчи FSM сохранены. Блок anchor-mismatch в reconcile сверяется по id из свежей персист-истории, а не по «живой» строке. B. Вход в attaching/reconnecting — ВСЕГДА через re-seed из персиста; «живой» стор НИКОГДА не база для tail-apply. На локальном FINISH_DISCONNECT (и на live-follow повторном дропе observer-а) сначала getRun(chatId) → замена «живой» частичной строки персистнутой по id (mergeById) + установка anchor, и лишь ПОСЛЕ этого диспатч RUN_FACT + FINISH_DISCONNECT (который планирует реконнект). Так attach не может продублировать частичный шаг N. Фильтр «живой» строки в resumeStream-эффекте убран (его заменяет re-seed). Инварианты FSM (I1 epoch-штамп, I4 honor-in-stopping, DISCONNECT-FIRST, сброс ownership на терминалах, render-gate) сохранены. C. URL attach: ?anchor=<id>&n=<stepsPersisted> при наличии якоря, без expect. D. Degraded-поллинг переведён с полного рефетча всех страниц на дельту: useAiChatMessagesQuery больше не поллит (seed один раз), а окно при degradedPoll раз в 2.5с зовёт getAiChatMessagesDelta(chatId, cursor) и идемпотентно по id мёржит строки в тот же infinite-query кэш через новый чистый хелпер mergeDeltaRowsIntoPages. Арминг/разарм (onResumeFallback) и idle-cap не тронуты. Хелперы: seedRows удалён; добавлены stepsPersistedOf и mergeDeltaRowsIntoPages (+ юнит-тесты на идемпотентность). Тесты chat-thread обновлены под новый URL, seed-без-стрипа, re-seed-из-персиста на дисконнекте (mutation-verify: падают без re-seed и при n мимо персиста) и 204→poll-без-restore. Весь ai-chat vitest зелёный (398), tsc без новых ошибок. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>Ре-ревью нашло регрессию класса #137/#161 на пути отказа getRun при tail-only re-seed: - НАХОДКА 1 (MEDIUM/HIGH): в onFinish-disconnect ветка .catch (отказ getRun) на локальном дропе входила в reconnect-ladder БЕЗ ре-сида и БЕЗ фильтра «живой» частичной строки. anchorRef оставался устаревшим (mount-инициализатор), живая частичная строка со шагами N..M-1 — последней; через ~1с реконнект строил ?anchor=&n=N_mount, и при живом ране с покрытием от N_mount (flaky-сеть: SSE и getRun упали, сеть поднялась за 1с) сервер отдавал кадры ≥N_mount → SDK дописывал их к строке, где они УЖЕ есть → дублирование (клиентского дедупа реплея против parts нет). Фикс: восстановлена структурная гарантия удалённого resumeStream- фильтра — на отказе getRun (и на no-persisted-row, и на no-cid) живая частичная строка удаляется из стора по id + anchorRef=null → реконнект реплеит со start в ЧИСТЫЙ стор (полная пересборка) либо 204→poll. Нет пути, где attach tail-applies на строку с уже присутствующими шагами. Тест: getRun-reject на локальном дисконнекте → живая строка отфильтрована + URL без параметров (mutation-verify: без фикса тест краснеет — фильтр не срабатывает). - НАХОДКА 2 (LOW): RUN_FACT в enterReconnect теперь epoch-штампуется (epoch: stampEpoch), как везде (postRun): getRun-rtt расширяет окно onFinish→dispatch, конкурентный SEND_LOCAL во время rtt теперь дропает устаревший RUN_FACT по I1, а не перетирает runFact.runId нового хода. - НАХОДКА 3 (LOW, doc): run-fsm.spec.md обновлён — stripRef/strippedRowRef → anchorRef {id, stepsPersisted}, tail-only + re-seed-from-persist. FSM run-fsm.ts не тронут; инварианты #488 (epoch/honor-in-stopping/ownership-reset/ disconnect-first/render-gate) сохранены. Клиент ai-chat vitest 399 зелёный, tsc 0 ai-chat-ошибок; сервер delta(6, реально исполняется)/registry/step-marker/attach + integration attach — зелёное. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>