Datadog is currently the only error source, which makes Nitpick unusable for teams whose errors already land in Sentry. Sentry is the most-requested first addition because its issue model (grouped events with a culprit and stack trace) maps closely onto the existing ErrorGroup.
Scope
- Implement
src/providers/sources/sentry.py against the existing source Protocol in src/providers/base.py.
- Map Sentry issues onto
ErrorGroup, reusing the existing fingerprint pipeline rather than adopting Sentry's own grouping, so dedup stays consistent across sources.
- Support project and environment filters equivalent to today's
datadog_query.
- Document required credentials in
.env.example and the README provider table.
Out of scope
Changing the normalized error model. If the Sentry shape does not fit ErrorGroup, that is worth discussing in this issue before widening the model.
Done when
A service configured with source: { type: sentry } completes a full run end to end, and tests cover the issue-to-ErrorGroup mapping including an event with no stack trace.
Datadog is currently the only error source, which makes Nitpick unusable for teams whose errors already land in Sentry. Sentry is the most-requested first addition because its issue model (grouped events with a culprit and stack trace) maps closely onto the existing
ErrorGroup.Scope
src/providers/sources/sentry.pyagainst the existing source Protocol insrc/providers/base.py.ErrorGroup, reusing the existing fingerprint pipeline rather than adopting Sentry's own grouping, so dedup stays consistent across sources.datadog_query..env.exampleand the README provider table.Out of scope
Changing the normalized error model. If the Sentry shape does not fit
ErrorGroup, that is worth discussing in this issue before widening the model.Done when
A service configured with
source: { type: sentry }completes a full run end to end, and tests cover the issue-to-ErrorGroupmapping including an event with no stack trace.