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.