BugSnag tracks the number of “sessions” that happen within your application. This allows you to compare stability scores between releases and helps you to understand the quality of your releases.
Sessions are captured and reported by default. This behavior can be disabled using the AutoTrackSessions configuration option.
BugSnag will automatically report a session each time the app is launched or enters the foreground after being in the background for at least 30 seconds.
Sessions are not automatically reported when playing using In-Editor Testing.
If you want control over what is deemed a session, you can switch off automatic session tracking with the Auto Track Sessions configuration option, and manage the session lifecycle using StartSession, PauseSession and ResumeSession on the UBugsnagFunctionLibrary.
You should call these methods at the appropriate time in your application’s lifecycle when you wish to have an active session. Any errors which occur in your application outside of a session will still be reported to BugSnag but will not count towards your application’s stability score.
Starts a new session to which subsequent handled and unhandled events will be attributed to.
UBugsnagFunctionLibrary::StartSession();
If there is already an active session, it will be replaced with a new one. Use ResumeSession if you only want to start a session when one doesn’t already exist.
Prevents further events being attributed to the current session until the session is resumed or a new session is started.
UBugsnagFunctionLibrary::PauseSession();
This can be advantageous if, for example, you do not wish the stability score to include crashes in a background service.
Resumes tracking events against the current session, if it was previously paused. If there is was no previous session, a new session is started. This method returns true if there was a session to resume or false if a new session was created.
UBugsnagFunctionLibrary::ResumeSession();
Sessions are stored in memory for the lifetime of the application process and are not persisted on disk. Therefore calling this method on app startup would start a new session, rather than continuing any previous session.
You can also control sessions from Blueprints using BugSnag’s “Start Session”, “Pause Session” and “Resume Session” actions.
The data captured in a session can be customized by adding an On Session callback as part of your initial BugSnag configuration.
Configuration->AddOnSession([](TSharedRef<IBugsnagSession> Session)
{
FString UserId = GetMyUserIdentifier();
Session->SetUser(UserId);
return true; // Return false to discard
});
The return value from the callback determines whether the session will be delivered to BugSnag and so can be used to discard sessions if required.
We recommend adding callbacks through BugSnag’s initial configuration (AddOnSession) to ensure that it is registered as soon as BugSnag starts. However, the following methods are provided to allow callbacks to be added and removed whilst the application is running:
UBugsnagFunctionLibrary::AddOnSession([](TSharedRef<IBugsnagSession> Session)
{
return true;
});
IBugsnagSession class The following information is available on the IBugsnagSession class, the representation of session information passed to in a session callback.
| property | type | description |
|---|---|---|
App |
App | A subset of the App data contained in error events. |
Device |
Device | A subset of the Device data contained in error events. |
Id |
String | A unique ID for the session. |
StartedAt |
DateTime | The timestamp that the session was started. |
User/SetUser |
User | The active user for the session. |