Back to Details

sentry-issue

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Sentry Issue Investigation

Sentry问题调查

Overview

概述

Fetch and debug a Sentry exception from a URL with a repeatable CLI workflow.
Core principle: Use 
sentry-cli
for auth/org/project discovery first, then fetch issue + event details. If your 
sentry-cli
version has no 
api
subcommand, use 
curl
with the same auth token.
通过可重复的CLI工作流，从URL中获取并调试Sentry异常。
核心原则： 优先使用
sentry-cli
进行身份验证/组织/项目发现，然后获取问题和事件详情。如果你的
sentry-cli
版本没有
api
子命令，则使用带有相同身份验证令牌的
curl
。

When to Use

使用场景

Use this skill when:
  • User gives a Sentry issue URL
  • You need stacktrace, request/job context, release, and tags
  • You need quick root-cause clues before changing code
Do not use this skill for generic app debugging without a Sentry issue reference.
在以下场景使用此技能：
  • 用户提供了一个Sentry问题URL
  • 你需要获取堆栈跟踪、请求/任务上下文、版本和标签信息
  • 在修改代码前需要快速找到根因线索
如果没有Sentry问题参考，请勿将此技能用于通用应用调试。

URL Parsing

URL解析

Given: 
https://buildrtech.sentry.io/issues/7261708580/?environment=demo&project=4510025524707328
Extract:
  • org slug: 
    buildrtech
  • issue id: 
    7261708580
  • project id: 
    4510025524707328
  • environment: 
    demo
    (if present)
给定URL： 
https://buildrtech.sentry.io/issues/7261708580/?environment=demo&project=4510025524707328
提取信息：
  • 组织标识（org slug）：
    buildrtech
  • 问题ID：
    7261708580
  • 项目ID：
    4510025524707328
  • 环境：
    demo
    （如果存在）

Workflow

工作流程

1) Verify CLI and auth

1) 验证CLI和身份验证

bash
sentry-cli --version
sentry-cli info
sentry-cli organizations list
sentry-cli projects list --org <org_slug>
Capture whether 
sentry-cli
has an 
api
command:
bash
sentry-cli --help
bash
sentry-cli --version
sentry-cli info
sentry-cli organizations list
sentry-cli projects list --org <org_slug>
检查
sentry-cli
是否有
api
命令：
bash
sentry-cli --help

2) Get high-level issue metadata

2) 获取高层级问题元数据

If 
sentry-cli
supports direct issue fetching in your version, use it. Otherwise use REST API with token from your Sentry CLI config.
Token discovery pattern:
bash
TOKEN=$(rg '^token=' ~/.sentryclirc | head -n1 | cut -d'=' -f2-)
Issue metadata:
bash
curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://sentry.io/api/0/issues/<issue_id>/"
This gives title, culprit, level, firstSeen, lastSeen, count, release, and status.
如果你的
sentry-cli
版本支持直接获取问题信息，请使用该功能。否则，使用Sentry CLI配置中的令牌调用REST API。
令牌获取方式：
bash
TOKEN=$(rg '^token=' ~/.sentryclirc | head -n1 | cut -d'=' -f2-)
获取问题元数据：
bash
curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://sentry.io/api/0/issues/<issue_id>/"
这将返回标题、问题源头、级别、首次出现时间、最后出现时间、出现次数、版本和状态。

3) Get latest event for stacktrace + request context

3) 获取最新事件以查看堆栈跟踪和请求上下文

bash
curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://sentry.io/api/0/issues/<issue_id>/events/latest/?environment=<env>"
If env is unknown, omit the environment query.
bash
curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://sentry.io/api/0/issues/<issue_id>/events/latest/?environment=<env>"
如果环境未知，可省略environment查询参数。

4) List all events for pattern analysis

4) 列出所有事件以分析模式

bash
curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://sentry.io/api/0/issues/<issue_id>/events/?environment=<env>"
Then inspect each event by ID:
bash
curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://sentry.io/api/0/issues/<issue_id>/events/<event_id>/?environment=<env>"
Use this to compare users, branches, params, releases, and frequency.
bash
curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://sentry.io/api/0/issues/<issue_id>/events/?environment=<env>"
然后通过ID查看每个事件的详情：
bash
curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://sentry.io/api/0/issues/<issue_id>/events/<event_id>/?environment=<env>"
使用此方法可以对比用户、分支、参数、版本和出现频率。

What to Extract

需要提取的信息

Always report:
  • Issue title/type/message
  • Culprit (controller/service/method)
  • First/last seen, count, status
  • Top in-app stack frames (file + line)
  • Request/job context (route, params, identifiers)
  • Environment, release, user info, request_id tags
  • Recurrence pattern (same path? same branch id? same commit type?)
务必报告以下内容：
  • 问题标题/类型/消息
  • 问题源头（控制器/服务/方法）
  • 首次/最后出现时间、出现次数、状态
  • 顶级应用内堆栈帧（文件+行号）
  • 请求/任务上下文（路由、参数、标识符）
  • 环境、版本、用户信息、request_id标签
  • 重复模式（相同路径？相同分支ID？相同提交类型？）

Debugging Standard (Root Cause First)

调试标准（优先找根因）

Before proposing fixes:
  1. Confirm exact throw site from in-app frame
  2. Trace caller chain in local code
  3. Match stacktrace behavior to request parameters
  4. Identify whether failure is expected business condition vs true system fault
  5. Propose fix at the boundary where error should be handled
在提出修复方案前：
  1. 从应用内堆栈帧确认确切的抛出位置
  2. 在本地代码中跟踪调用链
  3. 将堆栈跟踪行为与请求参数匹配
  4. 确定失败是预期的业务场景还是真正的系统故障
  5. 在应该处理错误的边界处提出修复方案

Output Template

输出模板

markdown
undefined
markdown
undefined

Sentry Issue: <title>

Sentry问题：<标题>

  • Issue ID: <id>
  • Env: <env>
  • Level: <level>
  • Status: <status>
  • First seen: <timestamp>
  • Last seen: <timestamp>
  • Occurrences: <count>
  • 问题ID：<id>
  • 环境：<env>
  • 级别：<level>
  • 状态：<status>
  • 首次出现：<timestamp>
  • 最后出现：<timestamp>
  • 出现次数：<count>

Error

错误信息

  • Type: <exception class>
  • Message: <message>
  • Culprit: <culprit>
  • 类型：<异常类>
  • 消息：<message>
  • 问题源头：<culprit>

In-app stacktrace highlights

应用内堆栈跟踪重点

  • path/to/file.rb:123 in 
    method_name
  • ...
  • path/to/file.rb:123 in 
    method_name
  • ...

Request/Job context

请求/任务上下文

  • Route/URL: <...>
  • Key params: <...>
  • User: <...>
  • Release: <...>
  • 路由/URL：<...>
  • 关键参数：<...>
  • 用户：<...>
  • 版本：<...>

Root cause hypothesis

根因假设

<why this fails based on evidence>
<基于证据分析失败原因>

Recommended fix

推荐修复方案

<where to handle and why> ```
<应在何处处理及原因>
undefined

Common Pitfalls

常见陷阱

  • Assuming 
    sentry-cli api
    exists in all versions (it may not)
  • Using issue list commands and expecting full stacktrace output
  • Ignoring environment filter and mixing unrelated events
  • Proposing fixes before confirming throw site and call chain
  • Treating expected domain errors as 500s instead of handling paths
  • 假设所有版本的
    sentry-cli
    都有
    api
    命令（实际可能没有）
  • 使用问题列表命令并期望获取完整的堆栈跟踪输出
  • 忽略环境过滤器，混合无关事件
  • 在确认抛出位置和调用链前就提出修复方案
  • 将预期的领域错误视为500错误，而非处理对应的流程

Quick Reference

快速参考

bash
undefined
bash
undefined

Auth/context

身份验证/上下文

sentry-cli info sentry-cli organizations list sentry-cli projects list --org <org>
sentry-cli info sentry-cli organizations list sentry-cli projects list --org <org>

Token from CLI config

从CLI配置中获取令牌

TOKEN=$(rg '^token=' ~/.sentryclirc | head -n1 | cut -d'=' -f2-)
TOKEN=$(rg '^token=' ~/.sentryclirc | head -n1 | cut -d'=' -f2-)

Issue

获取问题信息

curl -sS -H "Authorization: Bearer $TOKEN" "https://sentry.io/api/0/issues/<issue_id>/"
curl -sS -H "Authorization: Bearer $TOKEN" "https://sentry.io/api/0/issues/<issue_id>/"

Latest event

获取最新事件

curl -sS -H "Authorization: Bearer $TOKEN" "https://sentry.io/api/0/issues/<issue_id>/events/latest/?environment=<env>"
curl -sS -H "Authorization: Bearer $TOKEN" "https://sentry.io/api/0/issues/<issue_id>/events/latest/?environment=<env>"

Event list

获取事件列表

curl -sS -H "Authorization: Bearer $TOKEN" "https://sentry.io/api/0/issues/<issue_id>/events/?environment=<env>"
undefined
curl -sS -H "Authorization: Bearer $TOKEN" "https://sentry.io/api/0/issues/<issue_id>/events/?environment=<env>"
undefined