仪表盘

工单变成拉取请求。 中间的挖掘工作由Polylane完成。

加入候补名单

它先检查改了什么。 一半的工单都能追溯到某人做的一次变更。

Clouds prod-aws Changes

SQS visibility timeout lowered on checkout-events

Moderate impact configuration ·Synced 12 minutes ago

VisibilityTimeout on checkout-events dropped from 120s to 15s. Consumers that hold a message longer than 15 seconds will see it delivered twice; the dead-letter queue threshold is unchanged.

What we're watching
ApproximateAgeOfOldestMessage
checkout-events · baseline at change 3.2s · worse if up
Watching: no issue since this change
NumberOfMessagesReceived
checkout-events · baseline at change 41/min · worse if up
Watching: no issue since this change
Triggering events
SetQueueAttributes CloudTrail · deploy-bot · 12:41:02Z attached to this record's delta window
Full diff (3 changes)
Nodes (2) Edges (1)
2 nodes modified · 1 edge removed

假设要经检验,而不是被相信。 只有来自你真实系统的证据才能确认。

H1 Confirmed

Hyperdrive pool exhaustion after deploy 9f3c2a1

Confidence: strong · 3 of 3 passes

Prosecution confirmed
Defense confirmed
Neutral confirmed
H2 Refuted

Upstream PlanetScale degradation

Confidence: definitive · 3 of 3 passes

Prosecution refuted
Defense refuted
Neutral refuted
H3 Inconclusive

Cold-start regression in the new isolate

Confidence: weak · 2 of 3 passes

Prosecution inconclusive
Defense refuted
Neutral inconclusive

修复到达时已可审查。 包含根因、验证和差异。

github.com/coreplane/payments-api/pull/491

Cap retries on the checkout webhook worker #491

polylane
Open polylane wants to merge 1 commit into main from polylane/autofix/chat/k3x9f2-4e7d21a
Conversation 1 Commits 1 Checks 1 Files changed 2
polylane bot commented 6 minutes ago ···

Retries on the checkout webhook worker were unbounded: a failing delivery re-queued itself forever and amplified load on payments-api. This caps delivery at 5 attempts with exponential backoff and dead-letters the payload after the last one.

What changed

worker/deliver.ts gains MAX_DELIVERY_ATTEMPTS = 5 and backoff between attempts; exhausted payloads land in checkout-webhooks-dlq instead of re-queueing.

Validation

npm test — 214 passed. A forced failing delivery stopped after 5 attempts and appeared in the dead-letter queue.

Root cause · Why it's safe · Out of scope
polylane added commit 4e7d21a Verified
Review required At least 1 approving review is required
ci / test Successful in 3m 12s Details
Review required Waiting on your review: Polylane never merges on its own
Merging is blocked

Polylane如何工作。 它学习你的系统、监视它、调查,然后行动。

  • 它先学习你的系统

    上下文图映射你的云、仓库和可观测性提供商中的每一个资源和依赖。智能体基于真实拓扑推理,而不是猜测。

  • 无阈值检测

    每个提供商都有内置检查,再加上由你自己保存的查询和仪表盘生成的检查。统计分析和智能体共同判断,改善永远不会触发问题。

  • 有据可查的调查

    每一条结论都链接回背后的查询、日志行或变更记录。没有证据的判定回落为无法确定。

  • 写入是争取来的,从不默认拥有

    账户以只读方式连接。回滚默认关闭、受限速并留有记录。代码变更走你正常的审查流程。

  • 它每周都更敏锐

    记忆、每日笔记和用真实数据反复确认的监控查询:七月的调查能从六月的调查中学习。

它接入你已经在运行的一切。 以只读方式连接,然后开始。

常见问题。

我如何把工单交给Polylane?

在控制台、通过CLI或从编辑器通过MCP服务器发起一个线程,描述这个bug。智能体会带着工作区的完整上下文接手:图、遥测、变更记录和代码。

如果它找不到原因怎么办?

它会直说。调查以已解决、已诊断或无法确定结束:拿不到数据的调查永远不会给出确认,需要人来决定的事情会成为一次上报,而不是没完没了的追问。

它会从过去的工单中学习吗?

会。已确认的发现存为记忆,并在之后的线程中按语义检索,每日笔记持续记录发生了什么。七月的调查能从六月的调查中学习。

修复由谁来写?

默认由Polylane的自动修复完成:先调查,再编写并验证,附上推理。或者把实现交给Devin、Cursor或Factory。无论哪种方式,都由你审查。

它支持哪些仓库?

通过GitHub应用连接的GitHub仓库。修复落到受影响服务背后仓库的一个分支上,变更中链接到相应的调查。

更多使用场景

工单进,拉取请求出。 积压终于自己动起来了。