Skip to main content

每日 Sentry 错误修复

安排一个每日的高级 Devin 会话，在夜间拉取新的 Sentry 错误，为每个错误启动修复会话，并在早晨前准备好 PR。
AuthorCognition
Category自动化
Features计划, MCP, 高级
1

连接 Sentry MCP

在创建计划之前，Devin 需要访问你的 Sentry 数据。
  1. 前往 Settings > MCP Marketplace 并搜索 Sentry
  2. 点击 Enable 并通过 OAuth 进行身份验证 —— 这将授予 Devin 对你的 Sentry 问题（issues）、事件（events）和堆栈跟踪（stack traces）的只读访问权限
  3. 点击 Test listing tools 以验证连接是否正常
连接成功后，Devin 可以在会话中查询你的 Sentry 项目、获取问题详情和堆栈跟踪，并读取面包屑数据。了解更多：配置 MCP 服务器。
2

创建日程安排

Go to Settings > Schedules and click Create schedule。
  • Name: Daily Sentry remediation — payments-api
  • Frequency: 每天早上 6:00（这样修复 PR 在站会前就能准备好）
  • Agent: Advanced Devin — 让 Devin 为每个错误启动单独会话，从而并行执行修复
  • Slack channel: 选择一个频道（例如 #sentry-fixes），这样在运行完成并且 PR 准备好供评审时，你的团队会收到通知
  • Prompt:
3

使用你的代码库和历史修复为 Knowledge 初始化内容

当 Devin 理解你的应用错误模式时，它能编写出更好的修复方案。与其手动编写 Knowledge 条目，不如运行一次 Advanced Devin 会话来分析你的代码库和以往修复记录，然后让它创建 Knowledge：当 Devin 在计划任务运行期间遇到匹配的错误时，这些条目会被自动调用——而上面的定时提示会指示 Devin 基于你的 PR 反馈更新 Knowledge，从而随着时间的推移不断改进。
4

一次典型运行的输出

每天早晨，Devin 会处理夜间产生的错误队列，并创建有针对性的 PR。以下是一段真实会话输出的示例：
Processed 5 Sentry errors from payments-api (past 24h):

1. TypeError: Cannot read property 'last4' of null (1,892 events)
   Root cause: Stripe webhook delivers `payment_method: null` for
   bank transfer payments. CheckoutReceipt.tsx:34 destructures
   without a null check.
   PR #612: Add null safety to CheckoutReceipt, show "Bank Transfer"
   fallback for non-card payments.

2. TimeoutError: Query timeout after 30s on /api/invoices (743 events)
   Root cause: N+1 query in InvoiceService.getMonthly() — each
   line item triggers a separate product lookup.
   PR #613: Add eager loading for invoice line items with
   Sequelize `include`.

3. RangeError: Maximum call stack size exceeded (412 events)
   Root cause: Circular reference in refund.toJSON() when a
   refund references its parent transaction which references
   the refund.
   PR #614: Break circular ref with a custom serializer,
   add max-depth test.

4-5. Two lower-frequency validation errors — PRs #615, #616.
每个 PR（pull request）都包含一个 Sentry issue 链接、根因说明、修复方法，以及一项本可以捕获该原始错误的测试。
5

优化与迭代

After a week of runs, review what’s working and adjust:限定错误数量范围。 每次运行先从 top 5 个错误开始。如果 Devin 能稳定产出可直接合并的拉取请求（PR），可以增加到 8–10 个。如果修复需要大量人工修改，就降低到 3 个。按项目或标签过滤。 将提示缩小到特定的 Sentry 项目（payments-api、web-frontend），或排除噪声较大的标签。如果不同项目的错误量差异较大，可以为每个项目单独设置运行计划。从结果中学习。 运行几周后，开启一次 Advanced Devin 会话，分析哪些修复实际已经上线，并将结论整理进 Knowledge：