Dashbord

Fang issues før de når produksjon. Hver pull request gjennomgått mot det som er i drift, ikke bare diffen.

Bli med på ventelisten

Advarselen lander før sammenslåingen. Mekanismen, bevisene og fiksen: akkurat der du gjennomgår.

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

Den forbedrer koden, ikke bare vokter den. Manglende instrumentering legges til rett på grenen din.

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.

Og den fortsetter å følge med etter sammenslåingen. Det som slipper gjennom, fanges i produksjon.

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

Slik fungerer Polylane. Den lærer systemet ditt, følger med på det, undersøker og handler.

  • Den lærer systemet ditt først

    Kontekstgrafen kartlegger hver ressurs og avhengighet på tvers av skyene, repositoriene og observerbarhetsleverandørene dine. Agenter resonnerer over faktisk topologi, ikke gjetninger.

  • Deteksjon uten terskler

    Innebygde sjekker for hver leverandør, pluss sjekker generert fra dine egne lagrede spørringer og dashbord. En statistisk gjennomgang og en agent avgjør sammen, og en forbedring reiser aldri et issue.

  • Undersøkelser som viser belegg

    Hver påstand lenker tilbake til spørringen, logglinjen eller endringsoppføringen bak den. En konklusjon uten bevis faller tilbake til uavklart.

  • Skriving må gjøres fortjent, aldri antas

    Kontoer kobles til skrivebeskyttet. Rollbacks er av som standard, ratebegrenset og dokumentert. Kodeendringer går gjennom den vanlige gjennomgangen din.

  • Den blir skarpere hver uke

    Minner, dagsnotater og overvåkingsspørringer bekreftet på nytt mot ekte data: julis undersøkelse lærer av junis.

Den kobler seg på det du allerede kjører. Koble til skrivebeskyttet og start.

Spørsmål.

Hvordan fungerer KI-gjennomgang av pull requester?

Polylane kobles til GitHub som en app og gjennomgår hver pull request mot den levende infrastrukturen den deployes til: kontekstgrafen, gjeldende telemetri og nylige endringer. Konklusjonen lander som en kommentar pluss en sjekk kalt «Polylane production impact».

Kommer den til å blokkere sammenslåingene mine?

Bare hvis du vil. Krev sjekken «Polylane production impact» gjennom grenbeskyttelse, og risikable sammenslåinger blokkeres; la den være valgfri, og konklusjonen er rådgivende.

Er dette for KI-generert kode?

Det er for all kode. Det betyr bare mest når ingen leste endringen nøye: sikkerhetsnettet for KI-generert kode er den samme gjennomgangen som fanger den håndskrevne feilen.

Hvordan skiller dette seg fra CI?

CI kjører testene dine mot koden. Polylane gjennomgår endringen mot produksjon: konfigurasjonen, kapasiteten og avhengighetene den lander på, og telemetrien de sender ut akkurat nå. Den vises som en sjekk i den samme listen, og svarer på et annet spørsmål.

Vil den noen gang slå sammen eller deploye på egen hånd?

Nei. Endringer når standardgrenen din bare gjennom gjennomgangen din, og rollbacks til en tidligere kjent god deploy forblir av til du slår dem på.

Flere bruksområder

Lever i agentfart. Gjennomgått mot produksjon, hver gang.