[Data Forwarding integrations] Improve debuggability.
- Dominant language
- Python
- Stars
- 44.8k
- Forks
- 4.9k
- Avg merge
- 22h 21m
- Merged PRs (30d)
- 586
Description
### Problem Statement
With the current configuration and layout of the Project Settings -> Data Forwarding feature, it is difficult for users to identify why events are not being forwarded.
### Solution Brainstorm
Some options:
- Amazon SQS has a regex check for the bucket name, the UI does not warn the user the regex failed. The only way to see is by looking into the Sentry internal error for events with: `Invalid bucket name "{bucket name}"
Bucket name must match the regex "{REGEX}". The UI should show these warnings.
- Graph only shows forwarded event count, but no information if it was accepted or not. The UI could show status code for requests (similar to internal integration logs). Knowing the request had a 200, 400, 404... status response helps find the root cause.
- Add a test button to the page. It can send a dummy event to the server configured and show the response Sentry received.
### Product Area
Unknown
Contributor guide
Research direction
Start at Project Settings → Data Forwarding and review how SQS validation errors, forwarding responses, and integration logs are currently surfaced. The proposed options need to be narrowed to one specific behavior with acceptance criteria; done should mean the selected debuggability improvement is visible to users.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, observability-sre
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100