> ## Documentation Index
> Fetch the complete documentation index at: https://docs.codewarden.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Sentry

> Review a fix with the Sentry issue and its stack trace in view: setup, what is read, what is stored, and how to revoke.

When a pull request links a Sentry issue, CodeWarden reads the issue and the stack trace of its latest event, and shows them to the model next to the change. It then reports code it was shown that **would still raise the recorded error**, given the values the trace shows. These findings use the category `fix`.

CodeWarden never says an issue is fixed. Only running the failing case again can show that. What the review does state, as a fact it computes itself, is how many files of the stack trace the change touches:

```text theme={null}
Sentry issue WIDGETS-1: the change touches 1 of 2 file(s) in its stack trace.
```

## Requirements

* **Sentry SaaS** (`sentry.io`, US or EU region). Self-hosted Sentry is not supported.
* Permission in Sentry to create an internal integration in your organization.
* An [owner](/console/organizations-and-roles) of the organization in the CodeWarden console, to connect it.

## Set it up

<Steps>
  <Step title="Create an internal integration in Sentry">
    In Sentry, go to **Settings → Developer Settings → Custom Integrations** and create an **Internal Integration** for CodeWarden. Give it exactly these permissions:

    * **Issue & Event: Read**
    * **Organization: Read**

    Leave everything else at **No Access**. Save it and copy its token.
  </Step>

  <Step title="Paste it in the console">
    On the console's home page, open the installation and, under **Integrations**, open **Connect Sentry**. Enter your Sentry **organization slug** (the `acme` in `acme.sentry.io`) and the **internal integration token**, then click **Connect**.

    CodeWarden checks the token once against your organization before saving it, and learns which Sentry region to use from the answer.
  </Step>

  <Step title="Allow the projects in .codewarden.yml">
    Add the Sentry project slugs a pull request may link issues from, and merge it into the base branch:

    ```yaml .codewarden.yml theme={null}
    sentry:
      projects: ["widgets-api"]
      public_repositories: false
    ```

    Without this list no issue is read. On a public repository, nothing is read unless `public_repositories` is `true`.
  </Step>

  <Step title="Link the issue in the pull request">
    Put the issue's URL in the pull request's title or description:

    ```text theme={null}
    Fixes https://acme.sentry.io/issues/4507112233/
    ```

    The older form `https://sentry.io/organizations/acme/issues/4507112233/` works too. The URL must use the issue's **numeric id**; a short id such as `WIDGETS-1` is not matched.
  </Step>
</Steps>

## When an issue is read

All of these must hold. Otherwise the review runs without the issue, and the console shows why on the review's page.

1. The URL is in the pull request's title or description.
2. The URL's organization is the one connected to the installation. A link to any other organization is never read.
3. The repository is private, or `sentry.public_repositories` is `true`.
4. The connection is working.
5. The issue's project, as Sentry reports it, is listed in `sentry.projects`.

## What is read

Two read-only requests per review:

* **The issue**: its title, culprit, short id, status, level, event count, first and last seen, and its project.
* **Its latest event's stack trace.** CodeWarden keeps the five innermost frames that Sentry marks as your application's code, and matches their file names to paths in your repository.

Files from those frames that the pull request does not change are read from GitHub at the pull request's head commit, at most three, 25 lines either side of the frame's line. They are shown to the model **read-only**: CodeWarden never comments on them.

## What is stored

* **The token**, encrypted at rest. CodeWarden checks it once a day; if Sentry answers that it is not allowed (a 401 or 403), the connection is marked **needs reconnecting**.
* **On the review's record**: which issue was linked, the outcome of the read, the frames, which files were read and which the change touched.
* **The prompt sent to the model**, which includes the issue's details and the stack trace. It is kept with the review so every comment can be explained, as described in the [privacy policy](https://codewarden.co/legal/privacy/).

## Connection states

| State | Meaning |
| - | - |
| not connected | No token. Open **Connect Sentry**. |
| connected | Working. Owners can **Test connection**. |
| needs reconnecting | Sentry refused the token. Click **Remove**, then connect again with a valid token. |

## Disconnect and revoke

* **In the console:** an owner clicks **Disconnect** in the installation's Sentry box. The stored token is deleted.
* **In Sentry:** revoke the token, or delete the internal integration, under **Settings → Developer Settings**. Internal integration tokens do not expire on their own, so revoke the token when you stop using CodeWarden.

Connecting, disconnecting and a connection breaking all appear in the organization's [activity log](/console/activity-log).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.