You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #2163 we decided not to enforce rate limits on processed profiles with limit > 0, to prevent complexity (see PR description).
There is at least one case where a quota with limit:0 is also ignored though: When the metric gets extracted by an external relay (which does not receive quota config).
Investigate whether this can also happen for PoPs.
In #2163 we decided not to
enforce rate limits on processed profiles with `limit > 0`, to prevent
complexity (see PR description).
I wrongly assumed that quotas (i.e. rate limits with `limit:0`) would be
correctly enforced by dropping the profile envelope item before metrics
are extracted. I overlooked the fact that PoP Relays (where metrics are
extracted) do not _receive_ quota configuration, because they do not
request it:
https://github.com/getsentry/relay/blob/0505c88f932d89bd42ee75114440f7f08fe7d938/relay-server/src/actors/project_upstream.rs#L273
Note that this only affects rate limits that are issued _only_ for
profiles. Rate limits issued for _transactions_ correctly drop the
processed profiles.
This PR fixes the issue by stripping the `has_profile` tag off metrics
buckets if a `Profile` rate limit is active.
Fixes#2207
In #2163 we decided not to enforce rate limits on processed profiles with limit > 0, to prevent complexity (see PR description).
There is at least one case where a quota with limit:0 is also ignored though: When the metric gets extracted by an external relay (which does not receive quota config).
Investigate whether this can also happen for PoPs.
Possible solution: Reopen #2178
The text was updated successfully, but these errors were encountered: