sentry-react-native
sentry-react-native copied to clipboard
Session Tracking for apps that run in background
OS:
- [ ] Windows
- [x] MacOS
- [ ] Linux
Platform:
- [x] iOS
- [x] Android
SDK:
- [x]
@sentry/react-native
(>= 1.0.0) - [ ]
react-native-sentry
(<= 0.43.2)
SDK version: 1.4.5
react-native
version: 0.62.2
Are you using Expo?
- [ ] Yes
- [x] No
Are you using sentry.io or on-premise?
- [x] sentry.io (SaaS)
- [ ] on-premise
If you are using sentry.io, please post a link to your issue so we can take a look:
[Link to issue]
Configuration:
(@sentry/react-native
)
Sentry.init({
dsn: 'https://[email protected]/...'
// other options
release: `${appName}@${appVersion} (${buildNumber})`,
enableAutoSessionTracking: true,
sessionTrackingIntervalMillis: 30000,
});
I have following issue:
[Description] Hi, I have an app that purposefully runs in the background when a user starts a "session" with us. I would like to use the session tracking features, but I need to prevent the session from ending while the user's session with us is active.
I'm not aware of any manual way of tracking the session, nor that there's any option to change this configuration at runtime.
hey @sseppola thanks for raising this.
Right now the react-native SDK doesn't support manual sessions, but our native SDKs do support it, by calling startSession()
and endSession()
at your own time.
Eg Android: https://docs.sentry.io/platforms/android/#release-health
You could do that and call those methods directly from your react native bridge to the native layer Java/Kotlin.
Ps: If you intend to use the manual session tracking, disable the automatic session tracking.
We'll probably expose those methods on the native bridge as well if more people would have the same needs, thanks.
Ok, thanks
+1 for exposing startSession()
and endSession()
via the native bridge.
We need to manage our sessions manually: our app allows users to make VoIP calls, which are frequently long and with the app in the background.
With React Native, I'm attempting to set 'sessionTrackingIntervalMillis' to 172800000 (2days) with the expectation that the user will open the app at least once every 2 days... At best this is a dirty hack and I'll next attempt to use 604800000 (7d). At worst, it exposes some previously unknown memory leak.
I've reached out to Sentry via their support form. We'll see what they have to say about this.
@AlexAtkinson-Myant it probably would work but I'm afraid that the devices may starve in memory and the OS will kill the App before the session is able to be finished, looks like the best solution for this use case is disabling the automatic session handling and doing it manually, but if you have a React-native app, we'd need to expose startSession
and endSession
as described in the issue.
the OS could also kill the App if its just not being used for a while, that's another edge case.
This issue has gone three weeks without activity. In another week, I will close it.
But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog
or Status: In Progress
, I will leave it alone ... forever!
"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀
Another use case for this is Apps that are always in the foreground such as POS. In this case, users would need to start and finish a session manually, since we (the SDK) don't know when to start/finish it automatically.
Another use case for this is Apps that are always in the foreground such as POS. In this case, users would need to start and finish a session manually, since we (the SDK) don't know when to start/finish it automatically.
@marandaneto this is our exact use case. In the short term if I wanted to use this tool, is there a configuration to limit the maximum session time?
Yes https://docs.sentry.io/platforms/react-native/configuration/options/#hybrid-sdk-options
sessionTrackingIntervalMillis
If doing this, we can document and close https://github.com/getsentry/develop/issues/248 since we have to expose the methods in the sentry class.
+1! Our app, a self-order kiosk (basically a POS) is always running in the foreground, so the current Release Health / Crash Free Rate isn't accurately representing what we consider a "session". Would love to be able to control when a session starts and ends manually.