จับปัญหาก่อนที่จะถึง production ทุก pull request ถูกรีวิวเทียบกับสิ่งที่รันอยู่จริง ไม่ใช่แค่ diff

ลงชื่อเข้า waitlist

คำเตือนมาถึงก่อน 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

มันปรับปรุงโค้ด ไม่ใช่แค่กั้นไว้ instrumentation ที่ขาดหายถูกเพิ่มลงบน branch ของคุณเลย

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

Check Breached

checkout-edge P99 latency