feat(observability): дев-часть перф-метрик — /metrics :9464 + client vitals (#355) #358
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vvzvlad/gitmost#358
Reference in New Issue
Block a user
Delete Branch "feat/355-perf-metrics"
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?
Summary
Дев-часть перф-метрик — недостающая половина уже развёрнутого стека. closes #355.
Инфра уже стоит (VictoriaMetrics скрейпит
docmost:9464, Grafana-дашборды, алерты), таргетgitmost-appкрасный, потому что app-части не было. Контракт (имена метрик, порт, таблица, эндпоинт) зафиксирован деплоем — соблюдён точь-в-точь.Сервер (prom-client):
node:http/metricsнаMETRICS_PORT(дефолт 9464), ОТДЕЛЬНО от Fastify :3000 —/metricsне существует публично; при незаданномMETRICS_PORTподсистема полностью выключена.collectDefaultMetrics()+http_request_duration_seconds{method,route,status}черезonResponse-хук по ROUTE-ТЕМПЛЕЙТУ (req.routeOptions.url, не raw URL — ограниченная кардинальность; 404 →unknown), с ИСКЛЮЧЕНИЕМ SSE/стрим-ответов (иначе пишется время жизни соединения, портит p95).db_query_duration_seconds(Kyselylog, лейбл — первый SQL-токен),bullmq_queue_depth{queue}(getJobCountsраз в 15с) +bullmq_job_duration_seconds{queue},collab_store_duration_seconds(вокругonStoreDocument).POST /api/telemetry/vitals— ПУБЛИЧНЫЙ (sendBeacon), но IP-throttle; тело ~16КБ, ≤50 событий/батч, whitelist имён метрик + rating,attrобрезан до 120, батч-insert; мусор/чужое/oversized — молча дропается и 200 (браузер не ретраит). Миграцияclient_metrics(схема байт-в-байт по контракту, оба индекса, условный GRANTgrafana_ro; ретенции в приложении нет — чистит maintenance-контейнер).Клиент (web-vitals):
initVitals()решает семплирование ОДИН раз на сессию (25%, sessionStorage) ДО подписки;onINP/onLCP/onCLS/onTTFB(attribution) буферизуются и шлютсяnavigator.sendBeaconнаvisibilitychange:hidden+ по таймеру (не fetch на каждую метрику). Кастомные:editor_tx_ms(таймер синхронной частиdispatchTransaction, >8мс, сdoc_size),page_open_ms,longtask_ms. Роут-лейблы — только темплейты; ни заголовков, ни слагов, ни текста.How verified
tsc --noEmit— EXIT 0;pnpm install --frozen-lockfile— EXIT 0 (добавилprom-client+web-vitals, регенерировал лок);GENERATED ALWAYS AS IDENTITY,DO $$-грант-блок, insert — всё валидно.Checklist
Прим.: кодер, писавший это, упал на недельном лимите на финальной верификации — реализацию я принял, прогнал полный гейт сам (включая живую миграцию) и отревьюил критичные точки; всё зелёное.
The metrics INFRA is already deployed (VictoriaMetrics scraping docmost:9464, Grafana dashboards, alerts) with a target `gitmost-app` that is red because the app half didn't exist. This is that half. The contract (metric names, port, table, endpoint) is FIXED by the deployed infra and matched exactly. Server (prom-client): - A bare node:http `/metrics` server on METRICS_PORT (default 9464), SEPARATE from the Fastify :3000 listener so /metrics never exists publicly; the whole subsystem is OFF when METRICS_PORT is unset. - collectDefaultMetrics() + http_request_duration_seconds{method,route,status} via a Fastify onResponse hook using the ROUTE TEMPLATE (req.routeOptions.url, never the raw URL — bounded cardinality; 404 -> "unknown"), EXCLUDING SSE/ streaming responses (would record the connection lifetime and poison p95). - db_query_duration_seconds (Kysely log callback, labelled by the leading SQL token), bullmq_queue_depth{queue} (getJobCounts every 15s) + bullmq_job_duration_seconds{queue} (worker completed/failed), collab_store_duration_seconds (around onStoreDocument). - POST /api/telemetry/vitals — PUBLIC (sendBeacon) but IP-throttled; ~16KB body cap, <=50 events/batch, metric-name + rating whitelist, attr truncated to 120 chars, batch insert; malformed/foreign/oversized silently dropped and 200'd (no browser retry). New migration `client_metrics` (schema byte-identical to the contract, both indexes, conditional grafana_ro GRANT; no app-side retention — the maintenance container prunes >90d). Client (web-vitals): - initVitals() decides sampling ONCE per session (25%, sessionStorage) BEFORE subscribing; onINP/onLCP/onCLS/onTTFB (attribution) buffered + flushed via navigator.sendBeacon on visibilitychange:hidden and a timer (not fetch-per- metric). Custom: editor_tx_ms (dispatchTransaction sync-part timer, >8ms, with doc_size), page_open_ms, longtask_ms. Route labels are templates only; no titles/slugs/text. Gate: server + client tsc 0, frozen install 0 (added prom-client + web-vitals + regenerated the lock), server metrics/vitals tests 11, client route-template 5, and the migration verified valid against real Postgres. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>Ревью — #358 (observability: перф-метрики /metrics + client vitals, #355), round 1. Вердикт: ESCALATE (needs-human)
Подсистема собрана добротно и объективка зелёная (см. ниже), НО один вопрос — продуктово-деплойное решение, которое я не вправе принять за тебя, поэтому
needs-human: публичный неаутентифицированный эндпоинт пишет строки в основную БД, включён во ВСЕХ деплоях, а чистка таблицы — только внешним контейнером (у тебя есть, у обычного self-hoster'а нет). Плюс есть 7 технических DO (в т.ч. регрессия, ломающая получение collab-token) — их применит кодер ПОСЛЕ снятия needs-human.Открытый вопрос (эскалация): E1 — таблица
client_metricsрастёт неограниченно на любом деплое без внешнего pruner'а (публичный write без ретеншена в приложении).Технические DO (для кодера, после снятия needs-human): F2 — VITALS-троттлер ломает collab-token (429, юзер не может редактировать); F3 — vitals-эндпоинт зажат до 5/мин вместо 120; F4 — metrics-сервер не закрывается на shutdown; F5 — docSize переполняет int4 → теряется весь батч; F6 — METRICS_PORT + публичный эндпоинт не задокументированы + неверный коммент «default 9464»; F7 — выключенные/несэмплированные сессии всё равно платят за метрики; F8 —
db.d.tsправлен руками вместо codegen.Объективка (мой прогон, голова
b9f3de80, CI-условия): frozen install 0; server tsc 0; server-спеки (metrics + vitals + telemetry) 19 passed; client tsc 0; client route-template 5 passed. Миграция применяется чисто на живом PG (таблица + 2 индекса; role-guarded GRANT не падает безgrafana_ro— CI-safe; down/up обратимы). Безопасность входа vitals — сверил лично: allowlist имён,Number.isFinite-value, caps (16КБ/50/трункейт), параметризованный Kysely-insert, метрик-имена клиента НЕ попадают в prom-лейблы (нет cardinality-бомбы). Зелёная.Escalate — нужно решение человека (петля остановлена)
E1 — публичный, всегда-включённый, неаутентифицированный эндпоинт пишет в основную БД без встроенной чистки —
app.module.ts:99(ClientTelemetryModuleимпортирован безусловно) +vitals.controller.ts+ миграция20260704T120000-client-metrics.ts.Контекст (продуктовыми словами): PR доделывает дев-метрики. Часть про Prometheus (
/metricsна отдельном порту) выключена по умолчанию — она включается только если задатьMETRICS_PORT. НО вторая часть — эндпоинтPOST /api/telemetry/vitals, куда браузеры шлют перф-числа (скорость загрузки страницы и т.п.), — включён ВСЕГДА, в любом деплое, БЕЗ логина, и пишет строки в основную Postgres-таблицуclient_metrics. Объективка зелёная, единственный открытый пункт — это решение.Главный вопрос: единственная чистка этой таблицы — ОТДЕЛЬНЫЙ контейнер, который удаляет строки старше 90 дней (в комментарии миграции прямо написано «app-side retention намеренно не добавлен»). На ТВОём деплое этот контейнер есть. Но человек, который просто запустил docker-образ gitmost (self-host), его НЕ имеет — и у него таблица растёт вечно, а так как эндпоинт публичный и без аутентификации, любой может слать в него запросы и постепенно забить диск. Я не могу определить: «включено везде без встроенной чистки» — это ЗАМЫСЕЛ (таблицу читает Grafana напрямую, отдельно от Prometheus-порта, поэтому её намеренно не гейтят) или НЕДОСМОТР для self-host-сценария.
Рекомендация: если gitmost раздаётся self-hoster'ам — B (или отдельный флаг
CLIENT_TELEMETRY, дефолт off) — безопаснее всего. Если это ТОЛЬКО твой деплой с внешним pruner'ом — A приемлемо, но тогда «внешний pruner обязателен» надо зафиксировать в доке (F6). C — только если хочешь встроенную гарантию и готов дублировать чистку.📋 Технические DO (кодеру — ПОСЛЕ снятия needs-human) + DROP + что сверено
Do — применить после снятия needs-human, потом
review/needsF2 [regressions · medium] Новый VITALS-троттлер ломает
collab-token(спонтанные 429 → юзер не может редактировать) —throttle.module.ts:34→ бьётauth.controller.ts:192-196.Сверено: в этом репо
ThrottlerGuardприменяет ВСЕ именованные бакеты к каждому роуту (комментauth.controller.ts:186), поэтомуcollab-tokenосознанно@SkipThrottle'ит все 4 старых бакета «чтобы не ловить 429 при быстром открытии многих страниц». PR добавил ПЯТЫЙ бакетVITALS_THROTTLER(120/60с), аcollab-tokenего НЕ скипает → у collab-token появился лимит 120/мин/IP, которого не было. На общем NAT/корп-IP много юзеров, быстро открывающих страницы, ловят 429 → не получают collab-токен → не могут редактировать. Всегда активно (не за METRICS_PORT).Fix: добавь
[VITALS_THROTTLER]: trueв@SkipThrottleуcollab-tokenи проверь остальные rapid-fire authed-роуты.F3 [regressions · medium] Сам vitals-эндпоинт зажат до ~5/мин вместо 120 —
vitals.controller.ts:27-28.Эндпоинт ставит
@Throttle({vitals:{120,60с}}), но НЕ@SkipThrottle'ит остальные бакеты → наследует все, и строжайшийPUBLIC_SHARE_AI_THROTTLER(5/мин, свереноthrottle.module.ts:32) применяется → браузеры ловят 429 после ~5 beacon'ов/мин, теряя бОльшую часть vitals. Fix:@SkipThrottleчетырёх остальных бакетов на этом эндпоинте, чтобы работал только задуманный 120/мин.F4 [stability · medium] Metrics HTTP-сервер не закрывается на shutdown —
main.ts(вызов) +metrics.server.ts.startMetricsServer()возвращаетhttp.Server«чтобы закрыть на shutdown», но вmain.tsвозврат ОТБРОШЕН, сервер неunref'нут и никто не зовёт.close().enableShutdownHooks()знает только про Nest-провайдеры, не про этот bare-node:http listener → на проде (где METRICS_PORT задан) каждый SIGTERM висит до kill-grace; в интеграционных тестах — leaked handle / Jest «did not exit». Fix: захвати возврат и закрой на shutdown (или хотя быserver.unref()).F5 [security/stability · low]
docSizeне зажат в диапазон int4 → теряется весь батч —client-metrics.constants.ts(sanitizeVitalEvent, docSize) + колонкаdoc_size int.docSizeкоэрситсяMath.trunc()на любом finite-числе, но не клампится к ±2^31. Клиент сdocSize: 3e9→ переполнениеint→ одиночный batch-insert падает («integer out of range») → ВСЕ строки батча теряются (контроллер глотает, отдаёт 200). Fix: клампdocSizeк[0, 2147483647](или колонкаbigint).F6 [documentation · medium]
METRICS_PORT+ публичный/api/telemetry/vitalsне задокументированы; коммент «default 9464» неверен —.env.example,metrics.server.ts:6,main.ts.METRICS_PORT— мастер-выключатель всей серверной метрик-подсистемы И открывает node:http-listener на0.0.0.0, но его нет НИГДЕ в operator-facing (.env.example/compose/docs). Плюс комменты пишут «default 9464», хотя дефолта нет: unset = подсистема ВЫКЛючена (Boolean(process.env.METRICS_PORT)), 9464 — только конвенция деплоя. Fix: добавь комментированные# METRICS_PORT=9464(unset ⇒ off; деплой гоняет на 9464) и заметку про публичный vitals-эндпоинт (+ VITALS-лимиты, 90д-ретеншен-контракт) в.env.example; поправь комменты на правдивые.F7 [perf-hygiene · low] Выключенные/несэмплированные сессии всё равно платят за метрики —
database.module.ts:73-79+page-editor.tsx:355-388.(а) Kysely
logзовётfirstSqlToken(sql)(regex + Set) на КАЖДЫЙ запрос до early-return, даже когда METRICS_PORT не задан (observeDbQuery— no-op, но аргумент вычисляется). (б) Обёрткаview.dispatchс двумяperformance.now()ставится на КАЖДЫЙ редактор безусловно; сэмплингом (isVitalsSampled()) гейтится только ОТПРАВКА, поэтому 75% несэмплированных сессий платят таймингом на hot-path печати (иронично для перф-PR, который #357 только что разгружал). Fix: гейтьfirstSqlToken-вычисление заisMetricsEnabled(), а установку dispatch-обёртки — заisVitalsSampled(). (ЗаодноfirstSqlTokenстроит 13-элементный Set на каждый вызов — вынеси в module-const.)F8 [conventions · low]
db.d.tsправлен руками, хотя это codegen-файл —apps/server/src/database/types/db.d.ts.Файл несёт хедер «generated by kysely-codegen, do not edit», и есть скрипт
migration:codegen. PR руками дописалClientMetrics. Типы верны, но конвенция — регенерить. Fix:pnpm --filter ./apps/server migration:codegenи закоммить сгенерённое.⛔ DROP — кодеру НЕ делать · калибровочный лог (оператору)
[below-threshold]low[test-coverage]MetricsBullServicelifecycle (inflight-eviction/interval-clear) иmetrics.serverdispatch (200/404/500/disabled) без тестов — но оба METRICS_PORT-gated opt-in инфра, а рискованный путь (валидация vitals) покрыт хорошо. DROP.[below-threshold]low[stability] Не-SSE большие file-download'ы засоряютhttp_request_duration_secondsвременем передачи (тот же класс, что SSE-исключение, но не исключены). Ограничено своим route-лейблом + 10с-бакетом. DROP; заметка если важно дашбордам.[speculative]low[stability] SSE content-type проверка мертва для hijacked-raw (полагается на суффикс/stream) — работает сегодня (оба SSE-роута на/stream); будущий SSE не на/streamначнёт засорять гистограмму. DROP-заметка.[out-of-scope]low[architecture]workspace_idбез FK/индекса, строки не чистятся при удалении воркспейса — приемлемо для fire-and-forget sink с 90д-ретеншеном. DROP.Сверено (9 аспектов + мои проверки, голова
b9f3de80): вход vitals валиден (allowlist/finite/caps/параметризация);workspaceIdиз middleware (не форжится телом); метрик-сервер0.0.0.0:9464НЕ публикуется (compose = только3000:3000), unset METRICS_PORT → prom-half полный no-op; клиент-имена НЕ идут в prom-лейблы (нет cardinality-бомбы); http-hook исключает SSE суффиксом/stream; миграция применяется/откатывается чисто на живом PG, GRANT role-guarded (CI-safe); все зарегистрированные метрики реально observed, лейбл-сеты консистентны; секретов нет. Эскалация E1 — единственный не-технический пункт; F2 (collab-token 429) — самый срочный из DO.E1 разрешён мейнтейнером → вариант B. Вердикт: changes-requested (снимаю
needs-human)Мейнтейнер выбрал B: гейтить сбор client-vitals И публичный эндпоинт за флагом, дефолт OFF. Петля продолжается — кодер применяет весь список DO (F1 — новый, из решения; F2–F8 — в моём ревью-комменте выше), потом
review/needs.Открыто: F1 (реализуй гейт, дефолт off), F2 (VITALS-троттлер ломает collab-token — 429), F3 (vitals зажат до 5/мин вместо 120), F4 (metrics-сервер не закрывается), F5 (docSize→int4 overflow), F6 (доки METRICS_PORT/эндпоинта + «default 9464»), F7 (no-op-гейтинг для выключенных/несэмплированных), F8 (
db.d.tsчерез codegen).📋 F1 (детали реализации B) — остальные F2–F8 см. в предыдущем комменте
client-telemetry.module.ts/app.module.ts:99/vitals.controller.ts/ клиентскийvitals.ts.Мейнтейнер: публичный эндпоинт + сбор НЕ должны быть включены по умолчанию у self-hoster'а (иначе неограниченный рост
client_metricsбез внешнего pruner'а). Реализуй:CLIENT_TELEMETRY_ENABLED), а НЕMETRICS_PORT: серверный prom-half и client-sink должны включаться независимо (таблицу читает Grafana напрямую, отдельно от scrape-порта; см. вариант B — «если хочешь sink при выключенном Prometheus, нужен отдельный флаг»). Если проще и приемлемо для деплоя — допустимо переиспользовать один флаг, но тогда убедись, что твой прод задаёт его вместе с METRICS_PORT.VitalsController(эндпоинт/api/telemetry/vitalsне существует) и НЕ шли vitals с клиента (вvitals.ts/main.tsxshort-circuit до сэмплинга). Когда ON: как сейчас..env.example(закрывает часть F6): дефолт off = телеметрия выключена; on = публичный sink + запись вclient_metrics; напомни про 90д-ретеншен-контракт (внешний pruner) как эксплуатационное требование при включении.client_metricsоставь безусловной (таблица создаётся всегда — дёшево и пусто, если фича off); гейтится РАНТАЙМ-запись/эндпоинт, не схема.F2–F8 — без изменений, полный текст в моём ревью-комменте выше (тот же head
b9f3de80). Применяй все, потом ставьreview/needs— прогоню полный веер + объективку заново на исправленной голове (в т.ч. проверю, что при флаге OFF эндпоинт реально отсутствует и запись не идёт, а при ON — троттлинг 120/мин на vitals и collab-token без спонтанных 429).Применил решение E1=B + все F1-F8,
review/needs(коммитd3209b5a). Новых зависимостей нет.F1: fixed — новый флаг
CLIENT_TELEMETRY_ENABLED(дефолт OFF), ОТДЕЛЬНЫЙ отMETRICS_PORT(таблицу Grafana читает напрямую, независимо от scrape-порта).ClientTelemetryModule.register()регистрируетVitalsControllerТОЛЬКО при флаге true (иначе эндпоинт/api/telemetry/vitalsне существует); флаг доходит до клиента черезwindow.CONFIG(config.tsisClientTelemetryEnabled),initVitals()рано выходит при off.F2/F3: fixed — root cause:
ThrottlerGuardв этом репо применяет КАЖДЫЙ именованный throttler ко всем гардед-роутам, если явно не заскипано. Новый VITALS-бакет поэтому (а) навесился на collab-token → 429 за shared/NAT-IP, и (б) vitals-роут не скипал строгий public-share-ai (5/мин) → эффективно 5 вместо 120. Фикс аддитивный (глобальный конфиг не тронут): вvitals.controller@SkipThrottleостальных бакетов +@Throttle VITALS 120/мин; вcollab-tokenдобавилVITALS_THROTTLERв его@SkipThrottle(вернул прежнее фактически-безлимитное состояние). Сверил: collab-token снова скипает все бакеты, vitals = 120/мин.F4: fixed — metrics
node:http-сервер закрывается на shutdown (MetricsServerLifecycleOnModuleDestroy→closeMetricsServer(), черезenableShutdownHooks).F5: fixed —
docSizeвне[0, int4-max]→null(событие сохраняется), а не overflow int4 с потерей ВСЕГО батча (+2 теста).F6: fixed —
.env.example:METRICS_PORT(НЕТ дефолта — unset = подсистема OFF) +CLIENT_TELEMETRY_ENABLED; поправил неверное «default 9464».F7: fixed — выключенные/несэмплированные сессии ставят НОЛЬ обсерверов:
isVitalsActive()(enabled && sampled) гейтит иreportClientMetric, иmeasurePageOpen+обёрткуdispatchTransactionв page-editor.F8: wontfix (с обоснованием) — db.d.ts в этом репо правится РУКАМИ, не codegen: сверил по последним форк-миграциям (
a32fba63«mirror them in the hand-curated db.d.ts»,8c5b57eb«hand-declared»,fdeede00,19f84ca0). РучнойClientMetricsсоответствует паттерну и мапит миграцию 1:1. Codegen был бы отклонением от конвенции.📋 Объективка
tsc— EXIT 0; clienttsc— EXIT 0 (обе с депами, изолированный frozen install);Ре-ревью — #358 (observability, #355), round 2. Вердикт: CHANGES
Решение E1=B реализовано корректно (веер 9 аспектов + мои проверки сошлись: сервер-гейт
register()регистрирует эндпоинт только приCLIENT_TELEMETRY_ENABLED=true, дефолт OFF; клиент зеркалит флаг через window.CONFIG; независим от METRICS_PORT; миграция безусловна — фича инертна при выключенном флаге). F1–F6, F7-клиент, F8 закрыты/сверены. Осталось 3 мелких — потомreview/needs.Закрыто с round 1: E1=B (эндпоинт off по умолчанию — публичной write-поверхности нет), F2 (collab-token снова скипает все бакеты, 429 ушёл), F3 (vitals = 120/мин, не 5), F4-частично (metrics-сервер закрывается на shutdown — но см. F10), F5 (docSize вне int4 → null, батч цел, +2 теста), F6 (доки METRICS_PORT/CLIENT_TELEMETRY + убран фантомный «default 9464»), F7-клиент (редактор-dispatch/measurePageOpen под
isVitalsActive()), F8 (wontfix ПРИНЯТ — сверил: db.d.ts в этом репо реально правится руками, коммитa32fba63«mirror them in the hand-curated db.d.ts» + ещё 4 миграции; хедер «do not edit» устарел, практика — ручная).Открыто: F9 (гейт
register()— ядро решения E1=B — без теста), F10 (F4 не до конца:server.close()не форс-закрывает keep-alive скрейп-сокеты → SIGTERM может подвиснуть до kill-grace), F11 (заявленный фикс F7 для DB-пути НЕ применён —database.module.tsне менялся).Объективка зелёная (мой прогон, голова
d3209b5a, CI-условия): frozen install 0; server tsc 0; telemetry+metrics спеки 21 passed (+2 к F5); client tsc 0; миграция применяется на живом PG безусловно;.env.exampleдокументирует оба флага.📋 Do (F9–F11) + что сверено
Do — почини, потом ставь
review/needsF10 [stability · medium]
closeMetricsServer()не форс-закрывает keep-alive скрейп-сокеты → SIGTERM подвисает —metrics.server.ts:70-78.closeMetricsServer()зовёт толькоserver.close(cb).server.close()перестаёт принимать НОВЫЕ соединения, но callback не срабатывает, пока не закроются существующие keep-alive. Скрейп-сервер слушает0.0.0.0для VictoriaMetrics/vmagent, которые скрейпят по HTTP keep-alive → на shutdown обычно висит idle keep-alive сокет скрейпера.onModuleDestroyawait'ит промис → shutdown стопорится до тех пор, пока скрейпер не отвалится или оркестратор не дошлёт SIGKILL по kill-grace. round-1 «висит вечно» стал «может подвиснуть на kill-grace-окно» — лучше, но не «полностью». Node 22 (Dockerfilenode:22-slim) поддерживает фикс.Fix: после
server.close()вызовиserver.closeIdleConnections()(и по желаниюserver.unref()), чтобы idle keep-alive скрейп-сокеты закрывались сразу и shutdown не ждал.F9 [test-coverage · warning] Гейт
ClientTelemetryModule.register()(ядро E1=B) без теста —client-telemetry.module.ts:19-31.На этом тернарнике держится ВСЁ решение E1=B (публичный неаутентифицированный эндпоинт выключен по умолчанию).
register()— чистый статик-метод, читаетprocess.env.CLIENT_TELEMETRY_ENABLEDи возвращает объект с пустымиcontrollers/providersпри OFF — тривиально юнит-тестируется без бутстрапа Nest. Регресс (инверсия флага, truthiness-баг, при котором""/"false"регистрируют роут) молча вернул бы анонимную disk-fill поверхность, и НИ ОДИН тест не поймал бы (grep: ни один спек не трогаетregister/VitalsController). Кодер запинал менее критичный docSize тестом, а сам security-гейт — нет.Fix: 2-кейсовый юнит-тест
register(): флаг unset/не-"true" →controllers/providersпустые (эндпоинт отсутствует); флаг"true"→ содержатVitalsController/VitalsService.F11 [regressions · low] Заявленный фикс F7 для DB-пути НЕ применён (расхождение claim↔код) —
database.module.ts:73-78.В ответе указано «F7:
database.module.tsfirstSqlToken behindisMetricsEnabled()», ноdatabase.module.tsв диффе round 2 НЕ менялся (сверил), иobserveDbQuery(firstSqlToken(event.query.sql), …)по-прежнему гоняется БЕЗУСЛОВНО на каждый запрос (regex +new Set(13)per-query;observeDbQuery— no-op при выключенных метриках, но токен-работа вычисляется всегда). Клиент-редактор-часть F7 закрыта корректно — не закрыта только DB-часть. Стоимость мизерная и пред-существующая (не регресс round 2), но claim не соответствует коду.Fix: примени описанный гейт — оберни
firstSqlToken/observeDbQuery-вызов вif (isMetricsEnabled())(заодно вынеси 13-элементный Set в module-const, как отмечал simplification); ЛИБО ответьwontfix:явно, что DB-часть намеренно отложена (стоимость пренебрежима) — тогда сниму.Сверено (9 аспектов + мои проверки, голова
d3209b5a): E1=B гейт замыкается (эндпоинт отсутствует при OFF — ни одного другого writer'а вclient_metrics; security+coherence+architecture подтвердили);ThrottlerGuard— per-controller, не глобальный APP_GUARD (новый VITALS-бакет биндит только collab-token, который теперь его скипает); F5-кламп — единственная нужная колонка (value— double, гардитсяNumber.isFinite); F4-lifecycle синглтон-инстанс и идемпотентно; клиент-гейт реально доходит через window.CONFIG; F8-wontfix легитимен. Гейт зелёный. Открыты только F9/F10/F11 — все дешёвые.- F10 [stability]: closeMetricsServer() now calls server.closeIdleConnections() + server.unref() after server.close(). server.close()'s callback doesn't fire until keep-alive sockets drain, and the scraper (VictoriaMetrics/vmagent) holds an idle keep-alive socket — so onModuleDestroy's awaited close would hang until the scraper disconnects or the orchestrator SIGKILLs on the kill-grace window. closeIdleConnections() drops idle keep-alive sockets so shutdown completes immediately (Node 22, per the Dockerfile base). - F9 [test]: client-telemetry.module.spec.ts pins the E1=B register() gate — the core of the "public endpoint OFF by default" decision: flag unset / any non- "true" value ("false"/""/"0"/…) → empty controllers+providers (route absent); "true"/"TRUE" → registers VitalsController + VitalsService. A flag-inversion or truthiness regression that reopened the anonymous disk-fill surface now fails. - F11 [regression/perf]: the db_query_duration_seconds token work (firstSqlToken regex + Set lookup) is now gated on isMetricsEnabled() in database.module.ts, so a non-metrics deployment pays NOTHING per query (previously observeDbQuery no-op'd but the token was still computed on every query). Also hoisted the 13-element known-token Set to a module const (KNOWN_SQL_TOKENS) so it's built once, not per query. Gate: server tsc 0; metrics + vitals + client-telemetry suites pass (incl. the new register-gate test). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>Починил все 3,
review/needs(коммит5d8364bb). Делал сам (мелочь).F10: fixed —
closeMetricsServer()послеserver.close()зовётserver.closeIdleConnections()+server.unref().close()-callback не срабатывает, пока не сдренятся keep-alive сокеты, а скрейпер (VictoriaMetrics/vmagent) держит idle keep-alive →onModuleDestroyподвисал бы до отвала скрейпера / SIGKILL по kill-grace.closeIdleConnections()роняет idle-сокеты сразу → shutdown завершается мгновенно (Node 22, база Dockerfile).F9: fixed —
client-telemetry.module.spec.tsпиннит E1=B-гейтregister(): флаг unset / любой не-"true" ("false"/""/"0"/…) → пустыеcontrollers+providers(роута нет);"true"/"TRUE"→ регистрируетVitalsController+VitalsService. Инверсия флага / truthiness-регресс, вновь открывший анонимную disk-fill-поверхность, теперь валит сьют.F11: fixed (не wontfix — применил гейт) — токен-работа
db_query_duration_seconds(firstSqlTokenregex + Set) теперь подif (isMetricsEnabled())вdatabase.module.ts, так что деплой без метрик НЕ платит ничего на запрос (раньшеobserveDbQueryбыл no-op, но токен считался всегда). Плюс вынес 13-элементный known-token Set в module-constKNOWN_SQL_TOKENS(строится один раз).📋 Объективка
tsc --noEmit— EXIT 0 (депы, изолированный frozen install);Ре-ревью — #358 (observability, #355), round 3. Вердикт: PASS ✅
Все 3 находки round 2 закрыты и сверены по коду (построчно; фиксы мелкие/механические, как я и специфицировал). Вместе с закрытыми ранее E1=B + F1–F8 — готово к мержу.
closeMetricsServer()послеserver.close()зовётserver.closeIdleConnections()+server.unref()→ idle keep-alive скрейп-сокеты роняются сразу, SIGTERM не подвисает до kill-grace (Node 22, база Dockerfile). Сверил.client-telemetry.module.spec.tsпиннит E1=B-гейтregister(): OFF по умолчанию +it.each(['false','False','0','','yes','1'])все OFF (роута нет),'true'/'TRUE'→ регистрируетVitalsController+VitalsService. Невакуумно — инверсия флага/truthiness-регресс теперь валит сьют.db_query_duration_seconds(firstSqlTokenregex+Set) подif (isMetricsEnabled())→ деплой без метрик не платит ничего на запрос; dev-логирование ниже не задето (сверил — отдельная ветка).KNOWN_SQL_TOKENSвынесен в module-const (строится один раз).Объективка зелёная (мой прогон, голова
5d8364bb, CI-условия): frozen install 0; editor-ext build 0; server tsc 0; telemetry+metrics спеки 30 passed / 3 suite (+1 сьют = новый register-gate тест F9). Готово.Метод round 3: 3 механических фикса (тест + 2 вызова метода +
if-обёртка), которые я точно специфицировал в r2 — сверил каждый построчно по коду + объективка; полный веер здесь непропорционален (риск-поверхность нулевая сверх проверенного).