Дашборд

Ловите проблемы до того, как они дойдут до production. Каждый pull request проверяется относительно того, что работает, а не только diff.

Встать в список ожидания

Предупреждение приходит до merge. Механизм, доказательства и исправление: прямо там, где вы делаете ревью.

github.com/coreplane/orders-api/pull/482

Add trigram index for order search #482

Open rvidal wants to merge 1 commit into main from order-search-trgm
Conversation 1 Commits 1 Checks 2 Files changed 1
polylane bot commented 2 minutes ago ···
Caution

Merging this pull request may degrade production (high impact).

Merging this blocks every write to orders while the index builds. migrations/0114_order_search_trgm.sql:3 adds CREATE INDEX … USING gin (search_text gin_trgm_ops) without CONCURRENTLY, and a plain CREATE INDEX takes a full write lock on orders for the whole build. Checkout sustains ~38 writes/s on that table; each one queues behind the lock until the build finishes.

To make this safe: build the index with CREATE INDEX CONCURRENTLY outside the transactional migration.

orders-db · writes per second · last 48h projected lock window
02040
-48h -24h now
every one of these writes blocks while the index builds

Polylane analysed de91b47 for production impact.

Some checks were not successful 1 failing and 1 successful check
ci / test Successful in 2m 4s Details
Polylane production impact Non-concurrent index build locks writes on orders Details
Merging is blocked

Он улучшает код, а не только пропускает его через барьер. Недостающее инструментирование добавляется прямо в вашу ветку.

Clouds prod-cloudflare Key queries

Key queries

31 active · 2 telemetry gaps

Generated from your telemetry and your connected code, judged on observed data: every candidate ran against a day of real data before it was kept.

Did any payment capture fail? code answered
logs: "payment capture failed for order {orderId}"
declared in apps/api/src/payments.ts
Is the checkout webhook retrying more than usual? telemetry answered
metric: webhook.delivery.retries · rate over 5m
baseline 0.4/min over the observed day
Is the nightly reconciliation completing? code answered
logs: "reconciliation complete" · count over 24h
quiet all day: healthy. Kept because the code provably emits it
Are D1 writes hitting rate limits? telemetry unanswerable
no series found for this question
kept as a telemetry gap
Re-confirmed on every discovery run: one thin run cannot wipe a good set.

И он продолжает следить после merge. То, что проскочило, ловится в production.

Issues Critical latency degradation in checkout-edge worker Overview

Critical latency degradation in checkout-edge worker

Incident critical Polylane ·Detected 3 hours ago ·Last seen 4 minutes ago ·2 occurrences
OverviewInvestigationMetricsTimelineProperties
checkout-edge Cloudflare Worker

Critical latency degradation detected in checkout-edge worker: 18x+ P99 latency spikes sustained for 12 minutes

Causal metrics All metrics
Request Duration
414 ms ▲ 43.1σ
Wall Time
416 ms ▲ 43.0σ
CPU Time
14 ms ▲ 2.6σ
Blast radius
Search your cloud resources...
Graph Table
edge-gateway Cloudflare Worker ··· checkout-edge Cloudflare Worker ··· hd-prod Hyperdrive ··· payments-db PlanetScale ··· cart-svc Cloudflare Worker ···
Analysis Copy

Deploy 9f3c2a1 shrank the Hyperdrive pool hd-prod from 50 connections to 5. Under checkout load, requests queue on connection checkout and P99 rises 18× against the 30-minute baseline. Restoring the pool size restores latency.

Tags
service · checkout-edgeprovider · cloudflaredeploy · 9f3c2a1signal · wall_time_p99

Как работает Polylane. Он изучает вашу систему, следит за ней, расследует и действует.

  • Сначала он изучает вашу систему

    Граф контекста отображает каждый ресурс и каждую зависимость между вашими облаками, репозиториями и провайдерами наблюдаемости. Агенты рассуждают на основе реальной топологии, а не догадок.

  • Обнаружение без порогов

    Встроенные проверки для каждого провайдера плюс проверки, созданные из ваших сохранённых запросов и дашбордов. Статистический проход и агент решают вместе, и улучшение никогда не создаёт проблему.

  • Расследования, которые показывают доказательства

    Каждое утверждение ссылается на запрос, строку лога или запись об изменении, которые за ним стоят. Вердикт без доказательств откатывается к «неубедительно».

  • Право на запись нужно заслужить, оно не подразумевается

    Аккаунты подключаются только для чтения. Откаты выключены по умолчанию, ограничены по частоте и записываются. Изменения кода проходят через ваше обычное ревью.

  • Каждую неделю он становится точнее

    Записи памяти, ежедневные заметки и мониторинговые запросы, повторно подтверждённые на реальных данных: июльское расследование учится на июньском.

Он подключается к тому, что у вас уже работает. Подключите в режиме только чтения и начните.

Вопросы.

Как работает ИИ-ревью pull request'ов?

Polylane подключается к GitHub как приложение и проверяет каждый pull request относительно живой инфраструктуры, в которую он деплоится: графа контекста, текущей телеметрии и недавних изменений. Вердикт приходит как комментарий плюс проверка «Polylane production impact».

Будет ли он блокировать мои merge?

Только если вы этого хотите. Сделайте проверку «Polylane production impact» обязательной через защиту ветки, и рискованные merge будут заблокированы; оставьте её необязательной, и вердикт останется рекомендацией.

Это для кода, сгенерированного ИИ?

Это для любого кода. Просто важнее всего это тогда, когда никто не читал изменение внимательно: страховка для кода, сгенерированного ИИ, это то же ревью, которое ловит ошибку, написанную вручную.

Чем это отличается от CI?

CI запускает ваши тесты на коде. Polylane проверяет изменение относительно production: конфигурации, ёмкости и зависимостей, на которые оно ложится, и телеметрии, которую они излучают прямо сейчас. Он появляется как проверка в том же списке и отвечает на другой вопрос.

Будет ли он когда-нибудь делать merge или деплой самостоятельно?

Нет. Изменения попадают в вашу основную ветку только через ваше ревью, а откаты к предыдущему заведомо рабочему деплою остаются выключенными, пока вы их не включите.

Другие сценарии

Выпускайте со скоростью агентов. С проверкой относительно production, каждый раз.