Консоль

Ловіть проблеми до того, як вони дістануться продакшну. Кожен pull request перевіряється відносно того, що працює, а не лише diff.

Приєднатися до списку очікування

Попередження надходить до злиття. Механізм, докази і виправлення: саме там, де ви робите рев'ю.

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.

І він продовжує стежити після злиття. Те, що прослизнуло, ловиться в продакшні.

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».

Чи блокуватиме він мої злиття?

Лише якщо ви цього хочете. Зробіть перевірку «Polylane production impact» обов'язковою через захист гілок, і ризиковані злиття блокуються; залиште її необов'язковою, і висновок буде лише рекомендацією.

Це для коду, згенерованого ШІ?

Це для всього коду. Просто найважливіше це тоді, коли ніхто не читав зміну уважно: страхувальна сітка для коду, згенерованого ШІ, є тим самим рев'ю, яке ловить помилку, зроблену вручну.

Чим це відрізняється від CI?

CI запускає ваші тести на коді. Polylane перевіряє зміну відносно продакшну: конфігурації, потужностей і залежностей, на які вона лягає, і телеметрії, яку вони видають прямо зараз. Він з'являється як перевірка в тому самому списку, відповідаючи на інше питання.

Чи зливатиме або розгортатиме він щось самостійно?

Ні. Зміни потрапляють у вашу основну гілку лише через ваше рев'ю, а відкати до попереднього відомого справного розгортання залишаються вимкненими, доки ви їх не увімкнете.

Більше сценаріїв використання

Випускайте зі швидкістю агентів. З перевіркою відносно продакшну, кожного разу.