-
Notifications
You must be signed in to change notification settings - Fork 94
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
fix(profiles): Log ProfileIndexed outcome for rate limited profiles #2060
Merged
jjbayer
merged 7 commits into
feat/indexed-profile-outcomes
from
feat/indexed-profile-outcomes-ratelimit
Apr 24, 2023
Merged
fix(profiles): Log ProfileIndexed outcome for rate limited profiles #2060
jjbayer
merged 7 commits into
feat/indexed-profile-outcomes
from
feat/indexed-profile-outcomes-ratelimit
Apr 24, 2023
Conversation
This file contains 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
…e-outcomes-ratelimit
…nto feat/indexed-profile-outcomes-ratelimit
olksdr
approved these changes
Apr 24, 2023
jjbayer
added a commit
that referenced
this pull request
Apr 24, 2023
Improvement to #2054: Since #2054 already introduced a translation from `Profile` to `ProfileIndexed` for sampling outcomes, this PR does not change anything functionally. It is merely an attempt to be consistent with #2056 and #2060, such that we consider the `metrics_extracted` flag any time we generate a profiling outcome.
jjbayer
added a commit
that referenced
this pull request
Apr 26, 2023
…2071) In #2056, #2060 and #2061, I wrongly assumed that dropped profiles should always be counted as `ProfileIndexed` after metrics extraction and dynamic sampling, in order to not double-count towards `Profile`. This is wrong, because as the PR description of #2054 clearly states, profiles that are not dropped by dynamic sampling are only counted as accepted in processing relays, _after_ dynamic sampling and rate limiting: > In processing Relays, if an envelope still contains profiles after dynamic sampling, log an Accepted outcome for the "processed" category. By restricting this to processing Relays, we can be sure that every profile is only counted once. Instead of checking the `metrics_extracted` flag, introduce a new flag that explicitly states whether a profile was already counted towards `DataCategory::Profile` or not, and evaluate that flag instead of `metrics_extracted`.
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.
Improvement to #2054:
Same as #2056, but for rate limited outcomes: Before metrics extraction, rate limited profiles should count as
Profile
("processed" profile), because they have not been counted towards accepted profiles yet. after metrics extraction, they should count asProfileIndexed
.