search

open-telemetry / opentelemetry-android

OpenTelemetry Tooling for Android
Apache License 2.0
114 stars 22 forks source link

:bug: fix for timer getting reset on retrival of session id #467

Open Archish27 opened 3 days ago

Archish27 commented 3 days ago

Whenever we are getting session id, timer for sessionid idle gets updated. Ideally the timer should be updated only when the session is expired or reached maxed timeout.

Due to current behaviour, when accessing session id when app background the timer gets updated.

LikeTheSalad commented 2 days ago

Hi @Archish27

The current behavior is based on the idea that a session would last for as long as a user is using the app, this makes sense when looking at it from the perspective that a session is driven by a user's interaction at a given time, because of this, the way that a session would end is due to user inactivity (which is one of the reasons to end a session mentioned here) And another way could be by setting a hard stop max amount of time for a session (for example 4 hours) as a way to prevent sessions from becoming too large to be feasible to read/query later.

Based on the above, the existing behavior is working as intended, as we reset the timeout every time there's a new telemetry event happening, which is what we take as a signal that the app isn't "idle". If there's no telemetry data generated before the timeout expires, then we consider the app to be "idle" and that's when we create a new session.

However, having said that though, this idea of making sessions expire based on a fixed amount of time, or having to reset them, or having a max amount of time, etc, is something that's currently being discussed in the Client SIG (#otel-client-side-telemetry in Slack), where @bidetofevil is taking care of providing a detailed definition of what a session is, which will affect the way we're handling sessions in this project. Probably a new definition would allow for providing more customized logic where apps can decide when a session starts and ends based on the app's specific needs, so for now what I can recommend you is to have a look at Hanson's proposal here and provide some feedback if needed to try and find a solution that can suit different use cases.