Pano

Sorunları üretime varmadan yakala. Her pull request yalnızca diff'e değil, canlı olana karşı incelenir.

Bekleme listesine katıl

Uyarı birleştirmeden önce gelir. Mekanizma, kanıt ve düzeltme: tam inceleme yaptığın yerde.

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

Yalnızca kapı olmaz, kodu iyileştirir. Eksik enstrümantasyon doğrudan dalına eklenir.

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.

Ve birleştirmeden sonra izlemeye devam eder. Gözden kaçan ne varsa üretimde yakalanır.

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 nasıl çalışır. Sistemini öğrenir, izler, inceler ve harekete geçer.

  • Önce sistemini öğrenir

    Bağlam grafiği bulutların, depoların ve gözlemlenebilirlik sağlayıcıların boyunca her kaynağı ve bağımlılığı haritalar. Ajanlar tahminler değil, gerçek topoloji üzerinde akıl yürütür.

  • Eşiksiz tespit

    Her sağlayıcı için yerleşik kontroller, ayrıca kendi kaydettiğin sorgulardan ve panolardan üretilen kontroller. Bir istatistiksel geçiş ve bir ajan birlikte karar verir ve bir iyileşme asla sorun açmaz.

  • Kanıt gösteren incelemeler

    Her iddia arkasındaki sorguya, günlük satırına veya değişiklik kaydına bağlanır. Kanıtsız bir karar sonuçsuza düşer.

  • Yazmalar kazanılır, asla varsayılmaz

    Hesaplar salt okunur bağlanır. Geri almalar varsayılan olarak kapalı, hız sınırlı ve kayıt altındadır. Kod değişiklikleri normal incelemenden geçer.

  • Her hafta daha da keskinleşir

    Bellekler, günlük notlar ve gerçek veriye karşı yeniden doğrulanan izleme sorguları: temmuz incelemesi haziranınkinden öğrenir.

Zaten çalıştırdığın şeylere takılır. Salt okunur bağla ve başla.

Sorular.

Yapay zeka ile pull request incelemesi nasıl çalışır?

Polylane GitHub'a uygulama olarak bağlanır ve her pull request'i dağıtım yaptığı canlı altyapıya karşı inceler: bağlam grafiği, güncel telemetri ve yakın zamandaki değişiklikler. Karar bir yorum ve bir 'Polylane production impact' kontrolü olarak gelir.

Birleştirmelerimi engeller mi?

Yalnızca sen istersen. 'Polylane production impact' kontrolünü dal koruması üzerinden zorunlu kıl; riskli birleştirmeler engellenir. İsteğe bağlı bırak; karar tavsiye niteliğinde kalır.

Bu yapay zeka üretimi kod için mi?

Bütün kod için. Yalnızca kimse değişikliği dikkatle okumadığında en çok önem kazanır: yapay zeka üretimi kod için güvenlik ağı, elle yazılmış hatayı yakalayan incelemenin aynısıdır.

Bunun CI'dan farkı ne?

CI testlerini koda karşı çalıştırır. Polylane değişikliği üretime karşı inceler: üzerine indiği yapılandırma, kapasite ve bağımlılıklar ve bunların şu anda yaydığı telemetri. Aynı listede bir kontrol olarak görünür, farklı bir soruyu yanıtlar.

Hiç kendi başına birleştirir veya dağıtır mı?

Hayır. Değişiklikler varsayılan dalına yalnızca senin incelemenden geçerek ulaşır ve bilinen sağlam önceki bir dağıtıma geri almalar sen açmadığın sürece kapalı kalır.

Daha fazla kullanım senaryosu

Ajan hızında yayınla. Her seferinde üretime karşı incelenmiş.