-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(inbound-filters): Add inbound filter for ChunkLoadError #57277
Conversation
src/sentry/relay/config/__init__.py
Outdated
enable_chunk_upload_error_filter = project.get_option("filters:chunk-load-error") | ||
if enable_chunk_upload_error_filter: | ||
# ChunkLoadError: Loading chunk 3662 failed. (error: https://xxx.com/_next/static/chunks/29107295-0151559bd23117ba.js) | ||
error_messages += ["ChunkLoadError: Loading chunk * failed. (error: *)"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This glob pattern assumes that type
and value
for an error always exist and that the type is always ChunkLoadError
for all the errors of this type (e.g., there is no other type with the same error message).
enable_chunk_upload_error_filter = project.get_option("filters:chunk-load-error") | ||
if enable_chunk_upload_error_filter: | ||
# ChunkLoadError: Loading chunk 3662 failed.\n(error: https://xxx.com/_next/static/chunks/29107295-0151559bd23117ba.js) | ||
error_messages += ["ChunkLoadError: Loading chunk * failed.\n(error: *)"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You may want to check in a unit test in relay to make sure this pattern works. See for example getsentry/relay#1903.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did write a unit test for it, just wasn't sure if I should make a PR with it. wydt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we verified this works as expected?
with assume_test_silo_mode(SiloMode.CONTROL): | ||
assert AuditLogEntry.objects.filter( | ||
organization_id=project.organization_id, | ||
event=audit_log.get_event_id("PROJECT_EDIT"), | ||
).exists() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: what does this piece do? It seems duplicated for each option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I admit that I have replicated the test without thinking much about it but I have now removed it since semantically it does not make sense, since no mutation of the project options is happening between the checks.
tests/sentry/relay/test_config.py
Outdated
@@ -179,6 +179,7 @@ def test_project_config_uses_filter_features( | |||
default_project.update_option("sentry:error_messages", error_messages) | |||
default_project.update_option("sentry:releases", releases) | |||
default_project.update_option("filters:react-hydration-errors", False) | |||
default_project.update_option("filters:chunk-load-error", False) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should have a test to ensure this value produces a valid project config. If the feature is disabled, it won't be validated with the project config. If the config is invalid we will only see it in production when Relay is unable to parse the project config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep I was going to add it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the test in a follow up commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK to me
I am going to test locally. |
Hi there, if we plan on eventually adding this inbound filter to the UI, I'd prefer to use From an API perspective, it's a lot easier for our users if we group all the filter updates to this existing endpoint, and keep that documentation up-to-date. I'd be happy to help with anything as I've been trying to improve our API/documentation for a while now 🤠 |
Oh, nice, I didn't know we had this, I followed the implementation I was sent assuming it was the most up-to-date one, but it looks like not. I will fix it now. |
Codecov Report
@@ Coverage Diff @@
## master #57277 +/- ##
==========================================
+ Coverage 77.56% 78.93% +1.37%
==========================================
Files 5113 5117 +4
Lines 220581 222077 +1496
Branches 37346 37758 +412
==========================================
+ Hits 171094 175306 +4212
+ Misses 43783 41109 -2674
+ Partials 5704 5662 -42
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@schew2381 as discussed privately, we will continue with this implementation for now but we have created internally some tickets to track the work needed to make the system more extensible by extending the abstractions you mentioned and enabling proper outcomes generation for sub-filters inside of The spike ticket is here: #57359 |
For reference, this was the PR that contained the experimentation with the new abstractions: #57343 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK,
I personally prefer converting the option to bool ( and working with bool after that) but I guess it is a question of preference.
If you can, have a look at how we deal with this in other places in sentry.
I explained in chat the reason for having it as |
This PR implements a new inbound filter for
ChunkLoadError
s in the form:Such inbound filter idea emerged in vercel/next.js#38507.
Closes #57131