-
-
Notifications
You must be signed in to change notification settings - Fork 161
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
feat: Add support for pre-aggregated Sessions #284
Conversation
6adbe2d
to
8141d69
Compare
@@ -91,6 +116,8 @@ pub struct ClientOptions { | |||
/// is started at the time of `sentry::init`, and will persist for the | |||
/// application lifetime. | |||
pub auto_session_tracking: bool, | |||
/// Determine how Sessions are being tracked. | |||
pub session_mode: SessionMode, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we consider combining this with the session tracking flag into a session_mode: Application | Request | Off
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this a bit, and a tri-state would not work when you don’t want to have auto-tracking, but want to manually track request-mode sessions.
Also related to your other question: Request-Mode applies to all sessions, I updated the doc comment to accordingly. So choosing between application/request-mode basically means that you make a choice if you want aggregation at the cost of losing durations, or not.
Adds a new `session_mode` option that can be set to pre-aggregate sessions before they are sent upstream. This will allow efficient server applications that can produce thousands of session updates per second.
645d2d4
to
4260bbe
Compare
This should work together with getsentry/relay#815