✨[RUMF-430] new session strategy

[bcaudan]

Motivations

• Allow page with iframe displayed to continue to expand the session even if there is no interaction with the main page
• Reduce long lasting sessions

Changes

Behind the 'new-session' flag:

• Check page visibility every 1 minute to expand the session
• Add a session timeout at 4h
• Enforce the session expiration if last interaction was more than 15 minutes ago

[codecov-io]

Codecov Report

Merging #343 into master will increase coverage by 0.46%.
The diff coverage is 92.20%.

@@            Coverage Diff             @@
##           master     #343      +/-   ##
==========================================
+ Coverage   86.79%   87.26%   +0.46%     
==========================================
  Files          29       29              
  Lines        1621     1672      +51     
  Branches      333      344      +11     
==========================================
+ Hits         1407     1459      +52     
+ Misses        214      213       -1     

Impacted Files	Coverage Δ
packages/core/src/transport.ts	91.83% <0.00%> (ø)
packages/rum/src/performanceCollection.ts	63.79% <0.00%> (ø)
packages/rum/src/viewTracker.ts	93.75% <33.33%> (-1.49%)	⬇️
packages/core/src/sessionManagement.ts	100.00% <100.00%> (ø)
packages/core/src/utils.ts	96.09% <100.00%> (+0.33%)	⬆️
packages/logs/src/loggerSession.ts	100.00% <100.00%> (+4.54%)	⬆️
packages/rum/src/rumSession.ts	100.00% <100.00%> (ø)
packages/rum/src/userActionCollection.ts	98.73% <100.00%> (ø)
packages/logs/src/logger.ts	95.77% <0.00%> (+1.40%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0247a70...b3e79c8. Read the comment docs.

[BenoitZugmeyer]

IMO

• trackVisibility should expose an Observable instead of a callback function
• be self contained: no visibilityStateProvider, use document.visibilityState directly. We can mock document.visibilityState in tests

[bcaudan]

trackVisibility should expose an Observable instead of a callback function

what advantage do you see with it?

We can mock document.visibilityState in tests

How would you do that?

[BenoitZugmeyer]

what advantage do you see with it?

I think having a common strategy to pass data streams around would make things more future-proof. For now, our Observable implementation is quite limited, but in the future it could be extendend with a "destructor" when unused (example), and we would have a common way to remove listeners and stuff. This would make functions like this more self-contained and easier to test.

But if you feel that this is thinking too far ahead, I'm okay to keep a callback for now :)

How would you do that?

Object.defineProperty(document, 'visibilityState', { get() { return "zog" }, configurable: true })
// then
delete document.visibilityState

[bcaudan]

About observable instead of callbacks, I am not sure that observable pattern should be enforce in every situation.
I think it:

• allow us to easily reuse a data source in another part of the code
• can help us to decouple some of the browser API to the domain logic
  But it also adds an extra layer of abstraction.
  About future-proof arguments, let's see when we will have the need to do more complicated stuff with our observable and address it at this time.

In this case, I am not sure to see much benefit to switch to observable.

[BenoitZugmeyer]

OK