feat(integrations): push Sentry issue and installation events by webhook
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 18/100
Línea de trabajo
Start by reading the webhook contract delivered by #28 — the route, signature verification and Request-ID dedup this issue builds on — since nothing here can be written before that lands. Then read src/lib/adapters/sentry/ to see what fields the polling adapter already maps, and docs/providers/sentry.md ("Limitations", "Webhooks (Post-MVP)") for the documented gaps. Done means signed issue and installation deliveries enqueue on sync_jobs and reach the timeline via the existing event types, with unit tests over sanitized fixtures and the Playwright simulated-delivery spec passing under npm run lint, npm run typecheck, npm test.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Context
The Sentry adapter (#117, closed) is polling only, built under the "webhooks are Post-MVP" rule. Eddie's decision on #28 (2026-11-14): webhooks first, polling as the backfill, so timeline events arrive in near real time. Sentry is one of the first two providers, because its webhooks need no scope beyond the three read-only scopes the adapter already holds.
Today a Sentry issue event reaches the timeline up to an hour late, and regressions and resolutions are dated when the sync saw them, not when they happened (docs/providers/sentry.md, "Limitations"). An uninstall is only noticed when the next sync fails.
From Sentry's documentation, checked 2026-11-14:
| Item | Value | Source |
|---|---|---|
| Where the URL lives | One webhook URL on the integration's registration, with resource subscriptions | Webhooks |
| Signature | Sentry-Hook-Signature: HMAC SHA-256 hex digest of the raw body bytes, keyed with the client secret (SENTRY_CLIENT_SECRET, already set) |
Same page |
| Other headers | Sentry-Hook-Resource (installation, issue, ...), Sentry-Hook-Timestamp, Request-ID (unique per request) |
Same page |
| Response time | Within 1 second, or Sentry counts it as a timeout | Same page |
| Issue actions | created, resolved, assigned, archived, unresolved. A regression is unresolved with substatus: "regressed" |
Issue webhooks |
| Mapping | installation.uuid on every request maps a delivery to a connection |
Webhooks |
| Installation actions | created, deleted |
Installation webhooks |
| Releases and error volume | No webhook. Both stay polled | docs/providers/sentry.md, "Webhooks (Post-MVP)" |
Plan
- Implement the Sentry webhook declaration from the contract #28 adds: resources
installationandissue, verified withSentry-Hook-Signatureagainst the raw body in constant time, deduplicated onRequest-ID, replay-checked onSentry-Hook-Timestamp. - Map
installation.uuidto the stored installation id. Unknown installations are acknowledged and dropped. issuedeliveries become the existing event types, so the timeline shows one entry whichever path saw it first:createdtosentry.issue.created,unresolvedwithsubstatus: "regressed"tosentry.issue.regressed,resolvedtosentry.issue.resolved. Ignoreassignedandarchived. Regressions and resolutions are now dated by the delivery, not by the sync.- Read only the fields the adapter reads today (
id,shortId,status,substatus,level,firstSeen,lastSeen,permalink, project id). Never storetitle,culprit,metadata,assignedTo, oractor: they can carry personal data from the user's app. installation.deletedmarks the connection as needing a reconnect at once.- Answer within 1 second by queueing processing on
sync_jobs(#10). - Docs:
docs/providers/sentry.md(rename "Webhooks (Post-MVP)" to "Webhooks", update "Disconnect and revoke" and "Limitations", and change self-hosted registration step 4 to set the Webhook URL and subscribe to Issue).
Acceptance criteria
- A signed
issue.createddelivery puts a "New issue" event on the timeline within a minute, without waiting for a sync. - A regression and a resolution are dated by the delivery.
- The same issue event seen by webhook and then by polling shows once.
- An unsigned, wrongly signed, stale, or repeated delivery is rejected or ignored, and logged without its body.
-
installation.deletedmarks the connection as needing a reconnect. - No issue title, culprit, or actor is stored or logged.
- Polling still runs and still fills in error volume, releases, and any missed delivery.
- Unit tests on recorded, sanitized payloads from Sentry's documented samples. No live calls in CI.
- Playwright e2e: a signed delivery for the simulated Sentry provider appears on the timeline.
Files and areas
src/lib/adapters/sentry/(webhook handler, schemas, fixtures, tests), the webhook route from #28,docs/providers/sentry.md,docs/operations/oauth-apps.md.- Non-goals: new scopes,
error,comment, and alert resources, and pushing error volume (no webhook exists for it).
Verification
npm run lint,npm run typecheck,npm test- The Playwright spec for the simulated delivery.
Depends on
- #28 Ingest provider webhooks (contract, route, deduplication)
- #117 Add the Sentry adapter (closed)
Branch: <issue-number>-sentry-webhooks
Closes with a Closes #<issue-number> footer on the commit or pull request.
Model: anthropic/claude-opus-5-5 | Reasoning effort: unknown
- Lenguaje dominante
- TypeScript
- Estrellas
- 1
- Forks
- 1
- Merge medio
- 6 h 56 min
- PR fusionados (30 d)
- 136
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de eddiejaoude/StackDash
-
area: docs documentation priority: P3 size: S
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
eddiejaoude/StackDash#462 ·
Los mantenedores suelen responder en 1 día
-
area: web bug priority: P3 size: XS
Dificultad 1/5 1-3 horas Aptitud para principiantes 85/100
eddiejaoude/StackDash#432 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
area: database bug priority: P3 size: S
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
eddiejaoude/StackDash#419 ·
Los mantenedores suelen responder en 1 día
-
area: docs bug priority: P2 size: XS
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
eddiejaoude/StackDash#418 ·
Los mantenedores suelen responder en 1 día
-
accessibility area: timeline bug priority: P3 size: XS
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
eddiejaoude/StackDash#389 ·
Los mantenedores suelen responder en 1 día
Todos los issues de eddiejaoude/StackDash
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
open-webui/tether#52 ·
Los mantenedores suelen responder en 1 día
-
`void platform install --app-access public` fails when Cloudflare reports Access is disabledAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
voidzero-dev/void#835 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
AykutSarac/jsoncrack.com#616 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
melgarafael/DeskcommCRM#4679 ·
Los mantenedores suelen responder en 1 día