Skip to content
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

Conversation

jjbayer
Copy link
Member

@jjbayer jjbayer commented Apr 24, 2023

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 as ProfileIndexed.

@jjbayer jjbayer changed the base branch from master to feat/indexed-profile-outcomes April 24, 2023 09:57
@jjbayer jjbayer changed the title Feat/indexed profile outcomes ratelimit fix(profiles): Log ProfileIndexed outcome for rate limited profiles Apr 24, 2023
@jjbayer jjbayer marked this pull request as ready for review April 24, 2023 10:38
@jjbayer jjbayer requested review from a team, phacops and maheskett and removed request for a team April 24, 2023 10:38
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 jjbayer merged commit a301458 into feat/indexed-profile-outcomes Apr 24, 2023
@jjbayer jjbayer deleted the feat/indexed-profile-outcomes-ratelimit branch April 24, 2023 11:18
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants