feat(browser-reporting): Add ReportingEndpoint header when staff loads Sentry #93138
+102
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We want to start collecting browser reports on a temporary endpoint in S4S. This will only be enable for staff members. This is a temporary solution until we can build the proper Relay endpoint.
github-actions
bot
added
the
Scope: Backend
armenzg
changed the title
Codecov ReportAll modified and coverable lines are covered by tests ✅ ✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## master #93138 +/- ##
==========================================
+ Coverage 87.89% 87.90% +0.01%
==========================================
Files 10298 10309 +11
Lines 591455 592226 +771
Branches 23007 23007
==========================================
+ Hits 519876 520614 +738
- Misses 71143 71176 +33
Partials 436 436 |
lobsterkatie
approved these changes
Jun 10, 2025
Comment on lines
+23
to
+24
| staff = getattr(request, "staff", None) | ||
| if staff and staff.is_active: |
There was a problem hiding this comment.
pretty sure there's a helper for this that's supposed to be used instead?
| from django.http.response import HttpResponseBase | ||
|
|
||
|
|
||
| class ReportingEndpointMiddleware: |
There was a problem hiding this comment.
you may find the functional approach to middleware easier -- for instance sentry.middleware.env
Suspect IssuesThis pull request was deployed and Sentry observed the following issues:
Did you find this useful? React with a 👍 or 👎 |
lobsterkatie
added a commit
that referenced
this pull request
Jun 11, 2025
#93306) This adds an API endpoint, `api/0/reporting-api-experiment`, to collect deprecation, intervention, and crash reports enabled by the recently added[1] `Reporting-Endpoints` header This will hopefully get us a bit more real-world data to work with when deciding how we want to group/process/etc the reports. Since we don't yet know what kind of volume we're going to see, by default the endpoint is a no-op, and just returns a 404. However, if the new `issues.browser_reporting.collector_endpoint_enabled` option is set to `True` (as we are planning to do in S4S), the endpoint will log the incoming report to GCP and collect a metric on the overall report type. DISCLAIMER: This is proving hell on wheels to test locally. You have to proxy through an https server, it's unclear if the CORS and CSRF set up is correct, Chrome offers almost no data about the requests it's sending (and none at all unless you flip a hidden flag[2]), you have to run Chrome from the command line with a different hidden flag[3] in order to have the reports immediately rather than after a random delay... So thus far this endpoint has only been observed working a small handful of times, under circumstances that now seem unreplicable. However, since the entire thing is experimental and temporary (and by default doesn't do anything), we decided in the interest of time to just give it a shot and see what comes through. If we want to guarantee reports will be sent (to test if it's working at all), adding `navigator.vibrate(2000)` to our FE pageload will generate an intervention report, and adding `new Range().expand("dogs.are.great", 0, 1)` anywhere in our FE will generate a deprecation report. [1] #93138 [2] https://developer.chrome.com/docs/capabilities/web-apis/reporting-api#use_devtools [3] https://developer.chrome.com/docs/capabilities/web-apis/reporting-api#save_time
vishnupsatish
pushed a commit
that referenced
this pull request
Jun 12, 2025
#93306) This adds an API endpoint, `api/0/reporting-api-experiment`, to collect deprecation, intervention, and crash reports enabled by the recently added[1] `Reporting-Endpoints` header This will hopefully get us a bit more real-world data to work with when deciding how we want to group/process/etc the reports. Since we don't yet know what kind of volume we're going to see, by default the endpoint is a no-op, and just returns a 404. However, if the new `issues.browser_reporting.collector_endpoint_enabled` option is set to `True` (as we are planning to do in S4S), the endpoint will log the incoming report to GCP and collect a metric on the overall report type. DISCLAIMER: This is proving hell on wheels to test locally. You have to proxy through an https server, it's unclear if the CORS and CSRF set up is correct, Chrome offers almost no data about the requests it's sending (and none at all unless you flip a hidden flag[2]), you have to run Chrome from the command line with a different hidden flag[3] in order to have the reports immediately rather than after a random delay... So thus far this endpoint has only been observed working a small handful of times, under circumstances that now seem unreplicable. However, since the entire thing is experimental and temporary (and by default doesn't do anything), we decided in the interest of time to just give it a shot and see what comes through. If we want to guarantee reports will be sent (to test if it's working at all), adding `navigator.vibrate(2000)` to our FE pageload will generate an intervention report, and adding `new Range().expand("dogs.are.great", 0, 1)` anywhere in our FE will generate a deprecation report. [1] #93138 [2] https://developer.chrome.com/docs/capabilities/web-apis/reporting-api#use_devtools [3] https://developer.chrome.com/docs/capabilities/web-apis/reporting-api#save_time
andrewshie-sentry
pushed a commit
that referenced
this pull request
Jun 19, 2025
…s Sentry (#93138) We want to start collecting browser reports on a temporary endpoint in S4S. This will only be enabled for staff members. This is a temporary solution until we can build the proper Relay endpoint. It is intentional that: * It requires no auth since browsers do not send reports using user credentials * It is sent to s4s as we don't want any impact on saas The endpoint will be added in a different pull request. We will have an option to shut down the reporting if needed.
andrewshie-sentry
pushed a commit
that referenced
this pull request
Jun 19, 2025
#93306) This adds an API endpoint, `api/0/reporting-api-experiment`, to collect deprecation, intervention, and crash reports enabled by the recently added[1] `Reporting-Endpoints` header This will hopefully get us a bit more real-world data to work with when deciding how we want to group/process/etc the reports. Since we don't yet know what kind of volume we're going to see, by default the endpoint is a no-op, and just returns a 404. However, if the new `issues.browser_reporting.collector_endpoint_enabled` option is set to `True` (as we are planning to do in S4S), the endpoint will log the incoming report to GCP and collect a metric on the overall report type. DISCLAIMER: This is proving hell on wheels to test locally. You have to proxy through an https server, it's unclear if the CORS and CSRF set up is correct, Chrome offers almost no data about the requests it's sending (and none at all unless you flip a hidden flag[2]), you have to run Chrome from the command line with a different hidden flag[3] in order to have the reports immediately rather than after a random delay... So thus far this endpoint has only been observed working a small handful of times, under circumstances that now seem unreplicable. However, since the entire thing is experimental and temporary (and by default doesn't do anything), we decided in the interest of time to just give it a shot and see what comes through. If we want to guarantee reports will be sent (to test if it's working at all), adding `navigator.vibrate(2000)` to our FE pageload will generate an intervention report, and adding `new Range().expand("dogs.are.great", 0, 1)` anywhere in our FE will generate a deprecation report. [1] #93138 [2] https://developer.chrome.com/docs/capabilities/web-apis/reporting-api#use_devtools [3] https://developer.chrome.com/docs/capabilities/web-apis/reporting-api#save_time
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We want to start collecting browser reports on a temporary endpoint in S4S. This will only be enabled for staff members.
This is a temporary solution until we can build the proper Relay endpoint.
It is intentional that:
The endpoint will be added in a different pull request. We will have an option to shut down the reporting if needed.