fix(profiling): Classify profile chunks for rate limits and outcomes by Dav1dde · Pull Request #4595 · getsentry/relay

Dav1dde · 2025-03-20T14:36:39Z

This separates profile chunks into two separate categories. The category is determined by the platform contained within the item payload.

This does have several downsides:

No outcomes are emitted until the platform can be determined.
Rate limits happen only in processing (this is the only code which currently extracts the platform).

The plan is to hoist the platform into an item header, provided by the SDK directly. Once this happened we can reject all profile chunks without that necessary platform item and we can start rate limiting in the fast path.

Additionally we'll change Relay to make the executive decision whether a profile chunk is frontend/backend, this means we no longer need to make that decision in multiple places (they cannot diverge).

We will also need to consider how often the platforms change, we can extend Relay in a way where unknown platforms are just forwarded to processing but for the sake of rate limiting considered as the default category. Or just make the assignment configurable via global config.

The test test_profile_chunk_outcomes_rate_limited_via_profile_duration_rate_limit was never correct, the duration quota never worked it always just worked because it also contained the chunk category, but that is equivalent to the test above.

Fixes: https://github.com/getsentry/team-ingest/issues/679

loewenheim

Small typo, looks good otherwise

Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops · 2025-03-20T20:19:34Z

+ pub fn profile_type(&self) -> ProfileType {
+ match self.profile.platform.as_str() {
+ "cocoa" | "android" | "javascript" => ProfileType::Ui,
+ _ => ProfileType::Backend,
+ }
 }


phacops · 2025-03-20T20:20:05Z

+ /// The profile type is currently determined based on the contained profile
+ /// platform. It determines the data category this profile chunk belongs to.
+ ///
+ /// This needs to be synchronized with the implementation in Sentry:


If we can add the profile_type in the payload before we send it, this would become the source of truth.

I think we can use add it to the Kafka message https://github.com/getsentry/relay/blob/master/relay-server/src/services/store.rs#L1035-L1041 and the worker will handle it, no need to deserialize/serialize again.

Sure, that works, let's figure that out in a follow up where we wanna put it (payload / kafka header) and how it should look?

I would add it to the payload and not the header, it's easier to manipulate later on.

phacops · 2025-03-20T20:23:22Z

+ ItemType::ProfileChunk => match item.profile_type() {
+ Some(ProfileType::Backend) => !self.profile_chunks.is_active(),
+ Some(ProfileType::Ui) => !self.profile_chunks_ui.is_active(),
+ None => true,


Will this reject or accept profiles when we don't have a type?

It will accept when there is no type.

phacops · 2025-03-20T20:29:06Z

We started adding a platform field to SDKs, Relay should then classify the chunk based on this, add the type to the payload before we push to Kafka and become the source of truth.

We will also need to consider how often the platforms change

Platforms are not added very often, UI platforms even less often and rejecting the chunk for unknown/empty platforms is a good default.

Fixes: #4633. Followup to: #4595.

Dav1dde · 2025-03-20T14:36:39Z

This separates profile chunks into two separate categories. The category is determined by the platform contained within the item payload.

This does have several downsides:

No outcomes are emitted until the platform can be determined.
Rate limits happen only in processing (this is the only code which currently extracts the platform).

The plan is to hoist the platform into an item header, provided by the SDK directly. Once this happened we can reject all profile chunks without that necessary platform item and we can start rate limiting in the fast path.

Additionally we'll change Relay to make the executive decision whether a profile chunk is frontend/backend, this means we no longer need to make that decision in multiple places (they cannot diverge).

We will also need to consider how often the platforms change, we can extend Relay in a way where unknown platforms are just forwarded to processing but for the sake of rate limiting considered as the default category. Or just make the assignment configurable via global config.

The test test_profile_chunk_outcomes_rate_limited_via_profile_duration_rate_limit was never correct, the duration quota never worked it always just worked because it also contained the chunk category, but that is equivalent to the test above.

Fixes: https://github.com/getsentry/team-ingest/issues/679

loewenheim

Small typo, looks good otherwise

Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops · 2025-03-20T20:19:34Z

+ pub fn profile_type(&self) -> ProfileType {
+ match self.profile.platform.as_str() {
+ "cocoa" | "android" | "javascript" => ProfileType::Ui,
+ _ => ProfileType::Backend,
+ }
 }


phacops · 2025-03-20T20:20:05Z

+ /// The profile type is currently determined based on the contained profile
+ /// platform. It determines the data category this profile chunk belongs to.
+ ///
+ /// This needs to be synchronized with the implementation in Sentry:


If we can add the profile_type in the payload before we send it, this would become the source of truth.

I think we can use add it to the Kafka message https://github.com/getsentry/relay/blob/master/relay-server/src/services/store.rs#L1035-L1041 and the worker will handle it, no need to deserialize/serialize again.

Sure, that works, let's figure that out in a follow up where we wanna put it (payload / kafka header) and how it should look?

I would add it to the payload and not the header, it's easier to manipulate later on.

phacops · 2025-03-20T20:23:22Z

+ ItemType::ProfileChunk => match item.profile_type() {
+ Some(ProfileType::Backend) => !self.profile_chunks.is_active(),
+ Some(ProfileType::Ui) => !self.profile_chunks_ui.is_active(),
+ None => true,


Will this reject or accept profiles when we don't have a type?

It will accept when there is no type.

phacops · 2025-03-20T20:29:06Z

We started adding a platform field to SDKs, Relay should then classify the chunk based on this, add the type to the payload before we push to Kafka and become the source of truth.

We will also need to consider how often the platforms change

Platforms are not added very often, UI platforms even less often and rejecting the chunk for unknown/empty platforms is a good default.

Fixes: #4633. Followup to: #4595.

Dav1dde · 2025-03-20T14:36:39Z

This separates profile chunks into two separate categories. The category is determined by the platform contained within the item payload.

This does have several downsides:

No outcomes are emitted until the platform can be determined.
Rate limits happen only in processing (this is the only code which currently extracts the platform).

The plan is to hoist the platform into an item header, provided by the SDK directly. Once this happened we can reject all profile chunks without that necessary platform item and we can start rate limiting in the fast path.

Additionally we'll change Relay to make the executive decision whether a profile chunk is frontend/backend, this means we no longer need to make that decision in multiple places (they cannot diverge).

We will also need to consider how often the platforms change, we can extend Relay in a way where unknown platforms are just forwarded to processing but for the sake of rate limiting considered as the default category. Or just make the assignment configurable via global config.

The test test_profile_chunk_outcomes_rate_limited_via_profile_duration_rate_limit was never correct, the duration quota never worked it always just worked because it also contained the chunk category, but that is equivalent to the test above.

Fixes: https://github.com/getsentry/team-ingest/issues/679

loewenheim

Small typo, looks good otherwise

Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops · 2025-03-20T20:19:34Z

+ pub fn profile_type(&self) -> ProfileType {
+ match self.profile.platform.as_str() {
+ "cocoa" | "android" | "javascript" => ProfileType::Ui,
+ _ => ProfileType::Backend,
+ }
 }


phacops · 2025-03-20T20:20:05Z

+ /// The profile type is currently determined based on the contained profile
+ /// platform. It determines the data category this profile chunk belongs to.
+ ///
+ /// This needs to be synchronized with the implementation in Sentry:


If we can add the profile_type in the payload before we send it, this would become the source of truth.

I think we can use add it to the Kafka message https://github.com/getsentry/relay/blob/master/relay-server/src/services/store.rs#L1035-L1041 and the worker will handle it, no need to deserialize/serialize again.

Sure, that works, let's figure that out in a follow up where we wanna put it (payload / kafka header) and how it should look?

I would add it to the payload and not the header, it's easier to manipulate later on.

phacops · 2025-03-20T20:23:22Z

+ ItemType::ProfileChunk => match item.profile_type() {
+ Some(ProfileType::Backend) => !self.profile_chunks.is_active(),
+ Some(ProfileType::Ui) => !self.profile_chunks_ui.is_active(),
+ None => true,


Will this reject or accept profiles when we don't have a type?

It will accept when there is no type.

phacops · 2025-03-20T20:29:06Z

We started adding a platform field to SDKs, Relay should then classify the chunk based on this, add the type to the payload before we push to Kafka and become the source of truth.

We will also need to consider how often the platforms change

Platforms are not added very often, UI platforms even less often and rejecting the chunk for unknown/empty platforms is a good default.

Fixes: #4633. Followup to: #4595.

Dav1dde · 2025-03-20T14:36:39Z

This separates profile chunks into two separate categories. The category is determined by the platform contained within the item payload.

This does have several downsides:

No outcomes are emitted until the platform can be determined.
Rate limits happen only in processing (this is the only code which currently extracts the platform).

The plan is to hoist the platform into an item header, provided by the SDK directly. Once this happened we can reject all profile chunks without that necessary platform item and we can start rate limiting in the fast path.

Additionally we'll change Relay to make the executive decision whether a profile chunk is frontend/backend, this means we no longer need to make that decision in multiple places (they cannot diverge).

We will also need to consider how often the platforms change, we can extend Relay in a way where unknown platforms are just forwarded to processing but for the sake of rate limiting considered as the default category. Or just make the assignment configurable via global config.

The test test_profile_chunk_outcomes_rate_limited_via_profile_duration_rate_limit was never correct, the duration quota never worked it always just worked because it also contained the chunk category, but that is equivalent to the test above.

Fixes: https://github.com/getsentry/team-ingest/issues/679

loewenheim

Small typo, looks good otherwise

Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops · 2025-03-20T20:19:34Z

+ pub fn profile_type(&self) -> ProfileType {
+ match self.profile.platform.as_str() {
+ "cocoa" | "android" | "javascript" => ProfileType::Ui,
+ _ => ProfileType::Backend,
+ }
 }


phacops · 2025-03-20T20:20:05Z

+ /// The profile type is currently determined based on the contained profile
+ /// platform. It determines the data category this profile chunk belongs to.
+ ///
+ /// This needs to be synchronized with the implementation in Sentry:


If we can add the profile_type in the payload before we send it, this would become the source of truth.

I think we can use add it to the Kafka message https://github.com/getsentry/relay/blob/master/relay-server/src/services/store.rs#L1035-L1041 and the worker will handle it, no need to deserialize/serialize again.

Sure, that works, let's figure that out in a follow up where we wanna put it (payload / kafka header) and how it should look?

I would add it to the payload and not the header, it's easier to manipulate later on.

phacops · 2025-03-20T20:23:22Z

+ ItemType::ProfileChunk => match item.profile_type() {
+ Some(ProfileType::Backend) => !self.profile_chunks.is_active(),
+ Some(ProfileType::Ui) => !self.profile_chunks_ui.is_active(),
+ None => true,


Will this reject or accept profiles when we don't have a type?

It will accept when there is no type.

phacops · 2025-03-20T20:29:06Z

We started adding a platform field to SDKs, Relay should then classify the chunk based on this, add the type to the payload before we push to Kafka and become the source of truth.

We will also need to consider how often the platforms change

Platforms are not added very often, UI platforms even less often and rejecting the chunk for unknown/empty platforms is a good default.

Fixes: #4633. Followup to: #4595.

Dav1dde · 2025-03-20T14:36:39Z

This separates profile chunks into two separate categories. The category is determined by the platform contained within the item payload.

This does have several downsides:

No outcomes are emitted until the platform can be determined.
Rate limits happen only in processing (this is the only code which currently extracts the platform).

The plan is to hoist the platform into an item header, provided by the SDK directly. Once this happened we can reject all profile chunks without that necessary platform item and we can start rate limiting in the fast path.

Additionally we'll change Relay to make the executive decision whether a profile chunk is frontend/backend, this means we no longer need to make that decision in multiple places (they cannot diverge).

We will also need to consider how often the platforms change, we can extend Relay in a way where unknown platforms are just forwarded to processing but for the sake of rate limiting considered as the default category. Or just make the assignment configurable via global config.

The test test_profile_chunk_outcomes_rate_limited_via_profile_duration_rate_limit was never correct, the duration quota never worked it always just worked because it also contained the chunk category, but that is equivalent to the test above.

Fixes: https://github.com/getsentry/team-ingest/issues/679

loewenheim

Small typo, looks good otherwise

Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops · 2025-03-20T20:19:34Z

+ pub fn profile_type(&self) -> ProfileType {
+ match self.profile.platform.as_str() {
+ "cocoa" | "android" | "javascript" => ProfileType::Ui,
+ _ => ProfileType::Backend,
+ }
 }


phacops · 2025-03-20T20:20:05Z

+ /// The profile type is currently determined based on the contained profile
+ /// platform. It determines the data category this profile chunk belongs to.
+ ///
+ /// This needs to be synchronized with the implementation in Sentry:


If we can add the profile_type in the payload before we send it, this would become the source of truth.

I think we can use add it to the Kafka message https://github.com/getsentry/relay/blob/master/relay-server/src/services/store.rs#L1035-L1041 and the worker will handle it, no need to deserialize/serialize again.

Sure, that works, let's figure that out in a follow up where we wanna put it (payload / kafka header) and how it should look?

I would add it to the payload and not the header, it's easier to manipulate later on.

phacops · 2025-03-20T20:23:22Z

+ ItemType::ProfileChunk => match item.profile_type() {
+ Some(ProfileType::Backend) => !self.profile_chunks.is_active(),
+ Some(ProfileType::Ui) => !self.profile_chunks_ui.is_active(),
+ None => true,


Will this reject or accept profiles when we don't have a type?

It will accept when there is no type.

phacops · 2025-03-20T20:29:06Z

We started adding a platform field to SDKs, Relay should then classify the chunk based on this, add the type to the payload before we push to Kafka and become the source of truth.

We will also need to consider how often the platforms change

Platforms are not added very often, UI platforms even less often and rejecting the chunk for unknown/empty platforms is a good default.

Fixes: #4633. Followup to: #4595.

Dav1dde · 2025-03-20T14:36:39Z

This separates profile chunks into two separate categories. The category is determined by the platform contained within the item payload.

This does have several downsides:

No outcomes are emitted until the platform can be determined.
Rate limits happen only in processing (this is the only code which currently extracts the platform).

The plan is to hoist the platform into an item header, provided by the SDK directly. Once this happened we can reject all profile chunks without that necessary platform item and we can start rate limiting in the fast path.

Additionally we'll change Relay to make the executive decision whether a profile chunk is frontend/backend, this means we no longer need to make that decision in multiple places (they cannot diverge).

We will also need to consider how often the platforms change, we can extend Relay in a way where unknown platforms are just forwarded to processing but for the sake of rate limiting considered as the default category. Or just make the assignment configurable via global config.

The test test_profile_chunk_outcomes_rate_limited_via_profile_duration_rate_limit was never correct, the duration quota never worked it always just worked because it also contained the chunk category, but that is equivalent to the test above.

Fixes: https://github.com/getsentry/team-ingest/issues/679

loewenheim

Small typo, looks good otherwise

Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops · 2025-03-20T20:19:34Z

+ pub fn profile_type(&self) -> ProfileType {
+ match self.profile.platform.as_str() {
+ "cocoa" | "android" | "javascript" => ProfileType::Ui,
+ _ => ProfileType::Backend,
+ }
 }


phacops · 2025-03-20T20:20:05Z

+ /// The profile type is currently determined based on the contained profile
+ /// platform. It determines the data category this profile chunk belongs to.
+ ///
+ /// This needs to be synchronized with the implementation in Sentry:


If we can add the profile_type in the payload before we send it, this would become the source of truth.

I think we can use add it to the Kafka message https://github.com/getsentry/relay/blob/master/relay-server/src/services/store.rs#L1035-L1041 and the worker will handle it, no need to deserialize/serialize again.

Sure, that works, let's figure that out in a follow up where we wanna put it (payload / kafka header) and how it should look?

I would add it to the payload and not the header, it's easier to manipulate later on.

phacops · 2025-03-20T20:23:22Z

+ ItemType::ProfileChunk => match item.profile_type() {
+ Some(ProfileType::Backend) => !self.profile_chunks.is_active(),
+ Some(ProfileType::Ui) => !self.profile_chunks_ui.is_active(),
+ None => true,


Will this reject or accept profiles when we don't have a type?

It will accept when there is no type.

phacops · 2025-03-20T20:29:06Z

We started adding a platform field to SDKs, Relay should then classify the chunk based on this, add the type to the payload before we push to Kafka and become the source of truth.

We will also need to consider how often the platforms change

Platforms are not added very often, UI platforms even less often and rejecting the chunk for unknown/empty platforms is a good default.

Fixes: #4633. Followup to: #4595.

Dav1dde · 2025-03-20T14:36:39Z

This separates profile chunks into two separate categories. The category is determined by the platform contained within the item payload.

This does have several downsides:

No outcomes are emitted until the platform can be determined.
Rate limits happen only in processing (this is the only code which currently extracts the platform).

The plan is to hoist the platform into an item header, provided by the SDK directly. Once this happened we can reject all profile chunks without that necessary platform item and we can start rate limiting in the fast path.

Additionally we'll change Relay to make the executive decision whether a profile chunk is frontend/backend, this means we no longer need to make that decision in multiple places (they cannot diverge).

We will also need to consider how often the platforms change, we can extend Relay in a way where unknown platforms are just forwarded to processing but for the sake of rate limiting considered as the default category. Or just make the assignment configurable via global config.

The test test_profile_chunk_outcomes_rate_limited_via_profile_duration_rate_limit was never correct, the duration quota never worked it always just worked because it also contained the chunk category, but that is equivalent to the test above.

Fixes: https://github.com/getsentry/team-ingest/issues/679

loewenheim

Small typo, looks good otherwise

Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops · 2025-03-20T20:19:34Z

+ pub fn profile_type(&self) -> ProfileType {
+ match self.profile.platform.as_str() {
+ "cocoa" | "android" | "javascript" => ProfileType::Ui,
+ _ => ProfileType::Backend,
+ }
 }


phacops · 2025-03-20T20:20:05Z

+ /// The profile type is currently determined based on the contained profile
+ /// platform. It determines the data category this profile chunk belongs to.
+ ///
+ /// This needs to be synchronized with the implementation in Sentry:


If we can add the profile_type in the payload before we send it, this would become the source of truth.

I think we can use add it to the Kafka message https://github.com/getsentry/relay/blob/master/relay-server/src/services/store.rs#L1035-L1041 and the worker will handle it, no need to deserialize/serialize again.

Sure, that works, let's figure that out in a follow up where we wanna put it (payload / kafka header) and how it should look?

I would add it to the payload and not the header, it's easier to manipulate later on.

phacops · 2025-03-20T20:23:22Z

+ ItemType::ProfileChunk => match item.profile_type() {
+ Some(ProfileType::Backend) => !self.profile_chunks.is_active(),
+ Some(ProfileType::Ui) => !self.profile_chunks_ui.is_active(),
+ None => true,


Will this reject or accept profiles when we don't have a type?

It will accept when there is no type.

phacops · 2025-03-20T20:29:06Z

We started adding a platform field to SDKs, Relay should then classify the chunk based on this, add the type to the payload before we push to Kafka and become the source of truth.

We will also need to consider how often the platforms change

Platforms are not added very often, UI platforms even less often and rejecting the chunk for unknown/empty platforms is a good default.

Fixes: #4633. Followup to: #4595.

Dav1dde · 2025-03-20T14:36:39Z

This separates profile chunks into two separate categories. The category is determined by the platform contained within the item payload.

This does have several downsides:

No outcomes are emitted until the platform can be determined.
Rate limits happen only in processing (this is the only code which currently extracts the platform).

The plan is to hoist the platform into an item header, provided by the SDK directly. Once this happened we can reject all profile chunks without that necessary platform item and we can start rate limiting in the fast path.

Additionally we'll change Relay to make the executive decision whether a profile chunk is frontend/backend, this means we no longer need to make that decision in multiple places (they cannot diverge).

We will also need to consider how often the platforms change, we can extend Relay in a way where unknown platforms are just forwarded to processing but for the sake of rate limiting considered as the default category. Or just make the assignment configurable via global config.

The test test_profile_chunk_outcomes_rate_limited_via_profile_duration_rate_limit was never correct, the duration quota never worked it always just worked because it also contained the chunk category, but that is equivalent to the test above.

Fixes: https://github.com/getsentry/team-ingest/issues/679

loewenheim

Small typo, looks good otherwise

Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops · 2025-03-20T20:19:34Z

+ pub fn profile_type(&self) -> ProfileType {
+ match self.profile.platform.as_str() {
+ "cocoa" | "android" | "javascript" => ProfileType::Ui,
+ _ => ProfileType::Backend,
+ }
 }


phacops · 2025-03-20T20:20:05Z

+ /// The profile type is currently determined based on the contained profile
+ /// platform. It determines the data category this profile chunk belongs to.
+ ///
+ /// This needs to be synchronized with the implementation in Sentry:


If we can add the profile_type in the payload before we send it, this would become the source of truth.

I think we can use add it to the Kafka message https://github.com/getsentry/relay/blob/master/relay-server/src/services/store.rs#L1035-L1041 and the worker will handle it, no need to deserialize/serialize again.

Sure, that works, let's figure that out in a follow up where we wanna put it (payload / kafka header) and how it should look?

I would add it to the payload and not the header, it's easier to manipulate later on.

phacops · 2025-03-20T20:23:22Z

+ ItemType::ProfileChunk => match item.profile_type() {
+ Some(ProfileType::Backend) => !self.profile_chunks.is_active(),
+ Some(ProfileType::Ui) => !self.profile_chunks_ui.is_active(),
+ None => true,


Will this reject or accept profiles when we don't have a type?

It will accept when there is no type.

phacops · 2025-03-20T20:29:06Z

We started adding a platform field to SDKs, Relay should then classify the chunk based on this, add the type to the payload before we push to Kafka and become the source of truth.

We will also need to consider how often the platforms change

Platforms are not added very often, UI platforms even less often and rejecting the chunk for unknown/empty platforms is a good default.

Fixes: #4633. Followup to: #4595.

Dav1dde requested a review from a team as a code owner March 20, 2025 14:36

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch 3 times, most recently from f6de8a0 to 65c2067Compare March 20, 2025 17:13

Dav1dde self-assigned this Mar 20, 2025

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from 65c2067 to d53c559Compare March 20, 2025 17:35

fix(profiling): Classify profile chunks for rate limits and outcomes
4df7283

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from d53c559 to 4df7283Compare March 20, 2025 17:36

loewenheim reviewed Mar 20, 2025
View reviewed changes

Comment threadrelay-server/src/utils/rate_limits.rs Outdated

Update relay-server/src/utils/rate_limits.rs
db83783
Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops reviewed Mar 20, 2025
View reviewed changes

Comment threadtests/integration/test_filters.py Outdated

phacops approved these changes Mar 20, 2025
View reviewed changes

cleanup
20c270c

Dav1dde enabled auto-merge (squash) March 21, 2025 08:44

olksdr approved these changes Mar 21, 2025
View reviewed changes

Dav1dde merged commit cd67f90 into masterMar 21, 2025

Dav1dde deleted the dav1d/ratelimit-profile-chunks branch March 21, 2025 08:47

Litarnus approved these changes Mar 21, 2025
View reviewed changes

Dav1dde mentioned this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header #4636
Merged

Dav1dde added a commit that referenced this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header (#4636)
7868666
Fixes: #4633. Followup to: #4595.

Dav1dde mentioned this pull request Dec 23, 2025
ref(profile-chunks): Finally forbid profile chunk items without platform header #5507
Closed

Dav1dde requested a review from a team as a code owner March 20, 2025 14:36

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch 3 times, most recently from f6de8a0 to 65c2067Compare March 20, 2025 17:13

Dav1dde self-assigned this Mar 20, 2025

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from 65c2067 to d53c559Compare March 20, 2025 17:35

fix(profiling): Classify profile chunks for rate limits and outcomes
4df7283

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from d53c559 to 4df7283Compare March 20, 2025 17:36

loewenheim reviewed Mar 20, 2025
View reviewed changes

Comment threadrelay-server/src/utils/rate_limits.rs Outdated

Update relay-server/src/utils/rate_limits.rs
db83783
Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops reviewed Mar 20, 2025
View reviewed changes

Comment threadtests/integration/test_filters.py Outdated

phacops approved these changes Mar 20, 2025
View reviewed changes

cleanup
20c270c

Dav1dde enabled auto-merge (squash) March 21, 2025 08:44

olksdr approved these changes Mar 21, 2025
View reviewed changes

Dav1dde merged commit cd67f90 into masterMar 21, 2025

Dav1dde deleted the dav1d/ratelimit-profile-chunks branch March 21, 2025 08:47

Litarnus approved these changes Mar 21, 2025
View reviewed changes

Dav1dde mentioned this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header #4636
Merged

Dav1dde added a commit that referenced this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header (#4636)
7868666
Fixes: #4633. Followup to: #4595.

Dav1dde mentioned this pull request Dec 23, 2025
ref(profile-chunks): Finally forbid profile chunk items without platform header #5507
Closed

Dav1dde requested a review from a team as a code owner March 20, 2025 14:36

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch 3 times, most recently from f6de8a0 to 65c2067Compare March 20, 2025 17:13

Dav1dde self-assigned this Mar 20, 2025

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from 65c2067 to d53c559Compare March 20, 2025 17:35

fix(profiling): Classify profile chunks for rate limits and outcomes
4df7283

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from d53c559 to 4df7283Compare March 20, 2025 17:36

loewenheim reviewed Mar 20, 2025
View reviewed changes

Comment threadrelay-server/src/utils/rate_limits.rs Outdated

Update relay-server/src/utils/rate_limits.rs
db83783
Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops reviewed Mar 20, 2025
View reviewed changes

Comment threadtests/integration/test_filters.py Outdated

phacops approved these changes Mar 20, 2025
View reviewed changes

cleanup
20c270c

Dav1dde enabled auto-merge (squash) March 21, 2025 08:44

olksdr approved these changes Mar 21, 2025
View reviewed changes

Dav1dde merged commit cd67f90 into masterMar 21, 2025

Dav1dde deleted the dav1d/ratelimit-profile-chunks branch March 21, 2025 08:47

Litarnus approved these changes Mar 21, 2025
View reviewed changes

Dav1dde mentioned this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header #4636
Merged

Dav1dde added a commit that referenced this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header (#4636)
7868666
Fixes: #4633. Followup to: #4595.

Dav1dde mentioned this pull request Dec 23, 2025
ref(profile-chunks): Finally forbid profile chunk items without platform header #5507
Closed

Dav1dde requested a review from a team as a code owner March 20, 2025 14:36

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch 3 times, most recently from f6de8a0 to 65c2067Compare March 20, 2025 17:13

Dav1dde self-assigned this Mar 20, 2025

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from 65c2067 to d53c559Compare March 20, 2025 17:35

fix(profiling): Classify profile chunks for rate limits and outcomes
4df7283

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from d53c559 to 4df7283Compare March 20, 2025 17:36

loewenheim reviewed Mar 20, 2025
View reviewed changes

Comment threadrelay-server/src/utils/rate_limits.rs Outdated

Update relay-server/src/utils/rate_limits.rs
db83783
Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops reviewed Mar 20, 2025
View reviewed changes

Comment threadtests/integration/test_filters.py Outdated

phacops approved these changes Mar 20, 2025
View reviewed changes

cleanup
20c270c

Dav1dde enabled auto-merge (squash) March 21, 2025 08:44

olksdr approved these changes Mar 21, 2025
View reviewed changes

Dav1dde merged commit cd67f90 into masterMar 21, 2025

Dav1dde deleted the dav1d/ratelimit-profile-chunks branch March 21, 2025 08:47

Litarnus approved these changes Mar 21, 2025
View reviewed changes

Dav1dde mentioned this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header #4636
Merged

Dav1dde added a commit that referenced this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header (#4636)
7868666
Fixes: #4633. Followup to: #4595.

Dav1dde mentioned this pull request Dec 23, 2025
ref(profile-chunks): Finally forbid profile chunk items without platform header #5507
Closed

Dav1dde requested a review from a team as a code owner March 20, 2025 14:36

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch 3 times, most recently from f6de8a0 to 65c2067Compare March 20, 2025 17:13

Dav1dde self-assigned this Mar 20, 2025

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from 65c2067 to d53c559Compare March 20, 2025 17:35

fix(profiling): Classify profile chunks for rate limits and outcomes
4df7283

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from d53c559 to 4df7283Compare March 20, 2025 17:36

loewenheim reviewed Mar 20, 2025
View reviewed changes

Comment threadrelay-server/src/utils/rate_limits.rs Outdated

Update relay-server/src/utils/rate_limits.rs
db83783
Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops reviewed Mar 20, 2025
View reviewed changes

Comment threadtests/integration/test_filters.py Outdated

phacops approved these changes Mar 20, 2025
View reviewed changes

cleanup
20c270c

Dav1dde enabled auto-merge (squash) March 21, 2025 08:44

olksdr approved these changes Mar 21, 2025
View reviewed changes

Dav1dde merged commit cd67f90 into masterMar 21, 2025

Dav1dde deleted the dav1d/ratelimit-profile-chunks branch March 21, 2025 08:47

Litarnus approved these changes Mar 21, 2025
View reviewed changes

Dav1dde mentioned this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header #4636
Merged

Dav1dde added a commit that referenced this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header (#4636)
7868666
Fixes: #4633. Followup to: #4595.

Dav1dde mentioned this pull request Dec 23, 2025
ref(profile-chunks): Finally forbid profile chunk items without platform header #5507
Closed

Dav1dde requested a review from a team as a code owner March 20, 2025 14:36

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch 3 times, most recently from f6de8a0 to 65c2067Compare March 20, 2025 17:13

Dav1dde self-assigned this Mar 20, 2025

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from 65c2067 to d53c559Compare March 20, 2025 17:35

fix(profiling): Classify profile chunks for rate limits and outcomes
4df7283

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from d53c559 to 4df7283Compare March 20, 2025 17:36

loewenheim reviewed Mar 20, 2025
View reviewed changes

Comment threadrelay-server/src/utils/rate_limits.rs Outdated

Update relay-server/src/utils/rate_limits.rs
db83783
Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops reviewed Mar 20, 2025
View reviewed changes

Comment threadtests/integration/test_filters.py Outdated

phacops approved these changes Mar 20, 2025
View reviewed changes

cleanup
20c270c

Dav1dde enabled auto-merge (squash) March 21, 2025 08:44

olksdr approved these changes Mar 21, 2025
View reviewed changes

Dav1dde merged commit cd67f90 into masterMar 21, 2025

Dav1dde deleted the dav1d/ratelimit-profile-chunks branch March 21, 2025 08:47

Litarnus approved these changes Mar 21, 2025
View reviewed changes

Dav1dde mentioned this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header #4636
Merged

Dav1dde added a commit that referenced this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header (#4636)
7868666
Fixes: #4633. Followup to: #4595.

Dav1dde mentioned this pull request Dec 23, 2025
ref(profile-chunks): Finally forbid profile chunk items without platform header #5507
Closed

Dav1dde requested a review from a team as a code owner March 20, 2025 14:36

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch 3 times, most recently from f6de8a0 to 65c2067Compare March 20, 2025 17:13

Dav1dde self-assigned this Mar 20, 2025

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from 65c2067 to d53c559Compare March 20, 2025 17:35

fix(profiling): Classify profile chunks for rate limits and outcomes
4df7283

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from d53c559 to 4df7283Compare March 20, 2025 17:36

loewenheim reviewed Mar 20, 2025
View reviewed changes

Comment threadrelay-server/src/utils/rate_limits.rs Outdated

Update relay-server/src/utils/rate_limits.rs
db83783
Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops reviewed Mar 20, 2025
View reviewed changes

Comment threadtests/integration/test_filters.py Outdated

phacops approved these changes Mar 20, 2025
View reviewed changes

cleanup
20c270c

Dav1dde enabled auto-merge (squash) March 21, 2025 08:44

olksdr approved these changes Mar 21, 2025
View reviewed changes

Dav1dde merged commit cd67f90 into masterMar 21, 2025

Dav1dde deleted the dav1d/ratelimit-profile-chunks branch March 21, 2025 08:47

Litarnus approved these changes Mar 21, 2025
View reviewed changes

Dav1dde mentioned this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header #4636
Merged

Dav1dde added a commit that referenced this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header (#4636)
7868666
Fixes: #4633. Followup to: #4595.

Dav1dde mentioned this pull request Dec 23, 2025
ref(profile-chunks): Finally forbid profile chunk items without platform header #5507
Closed

Dav1dde requested a review from a team as a code owner March 20, 2025 14:36

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch 3 times, most recently from f6de8a0 to 65c2067Compare March 20, 2025 17:13

Dav1dde self-assigned this Mar 20, 2025

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from 65c2067 to d53c559Compare March 20, 2025 17:35

fix(profiling): Classify profile chunks for rate limits and outcomes
4df7283

Dav1dde force-pushed the dav1d/ratelimit-profile-chunks branch from d53c559 to 4df7283Compare March 20, 2025 17:36

loewenheim reviewed Mar 20, 2025
View reviewed changes

Comment threadrelay-server/src/utils/rate_limits.rs Outdated

Update relay-server/src/utils/rate_limits.rs
db83783
Co-authored-by: Sebastian Zivota <loewenheim@users.noreply.github.com>

phacops reviewed Mar 20, 2025
View reviewed changes

Comment threadtests/integration/test_filters.py Outdated

phacops approved these changes Mar 20, 2025
View reviewed changes

cleanup
20c270c

Dav1dde enabled auto-merge (squash) March 21, 2025 08:44

olksdr approved these changes Mar 21, 2025
View reviewed changes

Dav1dde merged commit cd67f90 into masterMar 21, 2025

Dav1dde deleted the dav1d/ratelimit-profile-chunks branch March 21, 2025 08:47

Litarnus approved these changes Mar 21, 2025
View reviewed changes

Dav1dde mentioned this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header #4636
Merged

Dav1dde added a commit that referenced this pull request Apr 2, 2025
ref(profiling): Infer profile type from item header (#4636)
7868666
Fixes: #4633. Followup to: #4595.

Dav1dde mentioned this pull request Dec 23, 2025
ref(profile-chunks): Finally forbid profile chunk items without platform header #5507
Closed

Uh oh!

Conversation

Dav1dde commented Mar 20, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

loewenheim left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

phacops commented Mar 20, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

Dav1dde commented Mar 20, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

loewenheim left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

phacops commented Mar 20, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

Dav1dde commented Mar 20, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

loewenheim left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Dav1dde commented Mar 20, 2025•
edited
Loading

Dav1dde commented Mar 20, 2025•
edited
Loading

Dav1dde commented Mar 20, 2025•
edited
Loading

Dav1dde commented Mar 20, 2025•
edited
Loading