You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we block Init to flush envelopes if there's anything on disk. Since the introduction of other envelope item types, we could be blocking Init for up to InitCacheFlushTimeout to flush out those items that could anyway be flushed asynchronously.
The goal behind InitCacheFlushTimeout and blocking init was to ensure crashes that happen right after Sentry is initialized and bring down the app are captured. We need to focus on that goal without the side effect of slowing down app starts for other reasons.
Suggested solution: On unhandled errors we write a marker file to disk such as crashed-at with a timestamp in it. This could be done exclusively on the UnhandledException integration and could be written by native integrations such as the iOS SDK for Unity. The SDK will only block to flush if such marker file exists. Additionally we should remove that marker file if we were able to flush the payload successfully before shutting down, which is expected on normal CLR/CoreCLR execution. This is mainly an issue on mobile where the OS often terminates the app if it tries to open a TLS connection (what we noticed during our Android tests on Java and C# unhandled exception handlers).
bruno-garcia
changed the title
Only block Init to flush events if the app crashed on the last run
Startup Crash: Only block Init to flush events if the app crashed on the last run
Apr 27, 2022
This feature can be added to any SDK that has offline caching. It came up in the iOS SDK: getsentry/sentry-cocoa#316 and possibly others.
Ideally we write a 'spec' that guides the implementation of it once we figure out the best approach
Currently we block Init to flush envelopes if there's anything on disk. Since the introduction of other envelope item types, we could be blocking
Init
for up toInitCacheFlushTimeout
to flush out those items that could anyway be flushed asynchronously.The goal behind
InitCacheFlushTimeout
and blocking init was to ensure crashes that happen right after Sentry is initialized and bring down the app are captured. We need to focus on that goal without the side effect of slowing down app starts for other reasons.Suggested solution: On unhandled errors we write a marker file to disk such as
crashed-at
with a timestamp in it. This could be done exclusively on the UnhandledException integration and could be written by native integrations such as the iOS SDK for Unity. The SDK will only block to flush if such marker file exists. Additionally we should remove that marker file if we were able to flush the payload successfully before shutting down, which is expected on normal CLR/CoreCLR execution. This is mainly an issue on mobile where the OS often terminates the app if it tries to open a TLS connection (what we noticed during our Android tests on Java and C# unhandled exception handlers).More context at: getsentry/sentry-unity#286 (comment)
The text was updated successfully, but these errors were encountered: