Late Init of sentry

[daniel-johns-99]

I read in the documentation that it's better to retrieve the Sentry DSN dynamically rather than embedding it in the app. But if I wait to fetch this configuration dynamically, I might miss events that occur during the wait, especially during app startup. Am I understanding this correctly? If I initialize Sentry 500ms after app start, will I lose events from the first 500ms?

Alternatively, is there a way to change configuration values after initialization? Specifically, I want to dynamically retrieve values for tracesSampleRate, sampleRate, and ignoreErrors, but I don't want to miss any events while waiting for these values before calling sentry.init. I know I can achieve this with an event processor, but I'd prefer using these built-in options before resorting to a custom solution.

Overall, I'm trying to understand the impact of delaying Sentry initialization versus initializing it immediately on app start and then adjusting configuration values once they're received (If that is even possible)

[krystofwoldrich]

Hi @daniel-johns-99,
thank you for the message,

you understand it correctly, when the SDK initialization is delayed all events (errors) that happened before the init will be lost.

Generally, when changing the options we recommend closing and re-initializing the SDK. As the options are used during the initialization process and later changes might not have the desired effect, a module where the value is used might not be included.

Typically undefined and 0 lead to the exclusion of a module during init.

Let us know if this helps.

[daniel-johns-99]

Generally, when changing the options we recommend closing and re-initializing the SDK.

Are there any impacts on doing this?

[krystofwoldrich]

Closing the SDK flushes events which are currently being processed, how this takes depends on the current state of the app, the amount of events and the connection speed.

[krystofwoldrich]

Closing this due to inactivity. If this is still an issue feel free to comment here or open a new issue if the context changed.

[realkosty]

Closing the SDK flushes events which are currently being processed, how this takes depends on the current state of the app, the amount of events and the connection speed.

@krystofwoldrich is close() synchronous or will close(); init(); result in potential loss of events?

I see that javascript supports then() + timeout while Shutdown and Draining page for React Native looks generic and suggests Sentry.flush() (presumably right before close()?).

[krystofwoldrich]

@realkosty

Yes, errors between the close() and init() would be lost. The same way as any errors before the SDK is initialized the first time.

The Sentry.close() calls flush() internally.

Yes, the Shutdown and Draining page for React Native is missing the close() function.

[realkosty]

@krystofwoldrich would it be a valid feature request to have an api similar to JS SDK or is this not possible in React Native because of architectural limitations?

Sentry.close(2000).then(function () { // ...

[krystofwoldrich]

@realkosty We already have it, without the timeout option.

import * as Sentry from `@sentry/react-native`;

Sentry.close(/* RN doesn't have the timeout property */).then(function () {});

[realkosty]

Oh nice! So it is possible then to implement close/re-init in such way that no events are lost.

[realkosty]

@krystofwoldrich
Customer is reporting that

Calling Sentry.close().finally(() => Sentry.init(options)) is resulting in this error from Sentry "Transport Disabled". As a result, app start and other transactions are failing to send.

any idea why that could be happening?

their Sentry configuration: #3816 (comment)

[krystofwoldrich]

I'm not sure, I will try to reproduce it and update my post here.

[daniel-johns-99]

@realkosty As a question. If I reinit sentry as proposed. Does it track as a new session in the release health? In addition what happens to any other transactions which are already open. Are they lost?
I seem to be losing the mobile performance metrics of time to start by doing the reinit of Sentry

[krystofwoldrich]

Hi @daniel-johns-99,
when the SDK is re-initialized, the currently running transactions will be lost.

A new session will be created.

Note that Sentry.close() closes the native SDKs, therefore when calling Sentry.init(options) the options should enabled the auto native init function or the native SDKs should be initialized manually as well.

[krystofwoldrich]

Closing this due to inactivity. If this is still an issue feel free to comment here or open a new issue if the context changed.