Skip to content

feat(inbound filters): Enable filtering sessions #4745

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

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

loewenheim
Copy link
Contributor

@loewenheim loewenheim commented May 16, 2025

This enables filtering for SessionUpdate and SessionAggregate items. In the course of this, it also

  • adds Filterable and Getter implementations to SessionUpdate and SessionAggregates;
  • introduces a SessionProcessingConfig struct to bundle all the auxiliary data needed in process_session and process_session_aggregates (modeled on ReplayProcessingConfig);
  • slightly refactors how session processing is called.

Aside from this not having tests, my main open questions are around the Getter impls. To wit:

  • Is there some sort of schema for what the path segments should be called? Is it just the names of the fields they return? Does anything break if they aren't chosen correctly?
  • Are the names for the "roots" of the two types appropriate? Should they be closer to the actual type names ("session_update"/"session_aggregates")?
  • Are there any fields I made addressable that shouldn't be?
  • In practical terms, do the Getter impls change anything about the way filtering works? I believe Filterable already returns the fields we actually care about.

Closes RELAY-41.

Comment on lines +2026 to +2027
&self.inner.global_config.current(),
&config,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here, we are getting passed the config from outside, but reading the global_config from self.inner. I did it this way because that's how it is in other processors (e.g. replays), but I don't know whether there's a good reason for it or it's a historical accident.

@loewenheim loewenheim linked an issue May 16, 2025 that may be closed by this pull request
@loewenheim loewenheim changed the title Sebastian/filter sessions feat(inbound filters): Enable filtering sessions May 16, 2025
Comment on lines +274 to +291
fn get_value(&self, path: &str) -> Option<relay_protocol::Val<'_>> {
let path = path.strip_prefix("session.")?;

match path {
"session_id" => Some(self.session_id.into()),
"distinct_id" => Some(self.distinct_id.as_deref()?.into()),
"sequence" => Some(self.sequence.into()),
"init" => Some(self.init.into()),
"duration" => Some(self.duration?.into()),
"errors" => Some(self.errors.into()),
"release" => Some(self.attributes.release.as_str().into()),
"environment" => Some(self.attributes.environment.as_deref()?.into()),
"ip_address" => Some(self.attributes.ip_address.as_ref()?.as_str().into()),
"user_agent" => Some(self.attributes.user_agent.as_deref()?.into()),
// TODO: status, abnormal mechanism?
_ => None,
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it would make sense to only expose the same fields in SessionUpdate and SessionAggregates so that generic filters would work in a similar fashion for both things

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.

Have option to exclude web crawlers from session tracking
2 participants