> ## 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

> Revisa un arreglo con el issue de Sentry y su stack trace a la vista: configuración, qué se lee, qué se guarda y cómo revocar.

Cuando un pull request enlaza un issue de Sentry, CodeWarden lee el issue y el stack trace de su evento más reciente, y se los muestra al modelo junto al cambio. Luego reporta el código que se le mostró y que **seguiría lanzando el error registrado**, dados los valores que muestra el trace. Estos hallazgos usan la categoría `fix`.

CodeWarden nunca dice que un issue está arreglado. Solo volver a ejecutar el caso que falla puede demostrarlo. Lo que la revisión sí afirma, como un dato que calcula por sí misma, es cuántos archivos del stack trace toca el cambio:

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

## Requisitos

* **Sentry SaaS** (`sentry.io`, región de EE. UU. o UE). Sentry autoalojado no es compatible.
* Permiso en Sentry para crear una integración interna en tu organización.
* Un [propietario](https://docs.codewarden.co/es/console/organizations-and-roles.md) de la organización en la consola de CodeWarden, para conectarlo.

## Configúralo

**1. Crea una integración interna en Sentry**

En Sentry, ve a **Settings → Developer Settings → Custom Integrations** y crea una **Internal Integration** para CodeWarden. Dale exactamente estos permisos:

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

Deja todo lo demás en **No Access**. Guárdala y copia su token.

**2. Pégalo en la consola**

En la página de inicio de la consola, abre la instalación y, bajo **Integraciones**, abre **Conectar Sentry**. Escribe el **slug de la organización** de Sentry (el `acme` de `acme.sentry.io`) y el **token de la integración interna**, y luego haz clic en **Conectar**.

CodeWarden verifica el token una vez contra tu organización antes de guardarlo, y averigua qué región de Sentry usar a partir de la respuesta.

**3. Permite los proyectos en .codewarden.yml**

Agrega los slugs de los proyectos de Sentry desde los que un pull request puede enlazar issues, y haz merge del cambio en la base branch:

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

Sin esta lista no se lee ningún issue. En un repositorio público, no se lee nada a menos que `public_repositories` sea `true`.

**4. Enlaza el issue en el pull request**

Pon la URL del issue en el título o la descripción del pull request:

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

La forma anterior `https://sentry.io/organizations/acme/issues/4507112233/` también funciona. La URL debe usar el **id numérico** del issue; un id corto como `WIDGETS-1` no coincide.

## Cuándo se lee un issue

Deben cumplirse todas. Si no, la revisión se ejecuta sin el issue, y la consola muestra por qué en la página de la revisión.

1. La URL está en el título o la descripción del pull request.
2. La organización de la URL es la conectada a la instalación. Un enlace a cualquier otra organización nunca se lee.
3. El repositorio es privado, o `sentry.public_repositories` es `true`.
4. La conexión funciona.
5. El proyecto del issue, según lo informa Sentry, está listado en `sentry.projects`.

## Qué se lee

Dos solicitudes de solo lectura por revisión:

* **El issue**: su título, culprit, id corto, estado, nivel, cantidad de eventos, primera y última vez visto, y su proyecto.
* **El stack trace de su evento más reciente.** CodeWarden conserva los cinco frames más internos que Sentry marca como código de tu aplicación, y compara sus nombres de archivo con rutas de tu repositorio.

Los archivos de esos frames que el pull request no cambia se leen de GitHub en el commit head del pull request, como máximo tres, 25 líneas a cada lado de la línea del frame. Se le muestran al modelo **en solo lectura**: CodeWarden nunca comenta en ellos.

## Qué se guarda

* **El token**, cifrado en reposo. CodeWarden lo verifica una vez al día; si Sentry responde que no está permitido (un 401 o 403), la conexión se marca como **requiere reconexión**.
* **En el registro de la revisión**: qué issue se enlazó, el resultado de la lectura, los frames, qué archivos se leyeron y cuáles tocó el cambio.
* **El prompt enviado al modelo**, que incluye los detalles del issue y el stack trace. Se guarda con la revisión para que cada comentario se pueda explicar, como se describe en la [política de privacidad](https://codewarden.co/es/legal/privacidad/).

## Estados de la conexión

| Estado | Significado |
| - | - |
| no conectado | Sin token. Abre **Conectar Sentry**. |
| conectado | Funciona. Los propietarios pueden **Probar conexión**. |
| requiere reconexión | Sentry rechazó el token. Haz clic en **Quitar**, y luego conecta de nuevo con un token válido. |

## Desconectar y revocar

* **En la consola:** un propietario hace clic en **Desconectar** en el cuadro de Sentry de la instalación. El token guardado se elimina.
* **En Sentry:** revoca el token, o elimina la integración interna, en **Settings → Developer Settings**. Los tokens de integraciones internas no expiran por sí solos, así que revoca el token cuando dejes de usar CodeWarden.

Conectar, desconectar y la rotura de una conexión aparecen en el [registro de actividad](https://docs.codewarden.co/es/console/activity-log.md) de la organización.


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