Repository navigation
Help with two questions #1185
Description
Environment
self-hosted (https://develop.sentry.dev/self-hosted/)
What are you trying to accomplish?
1.If my sentry-native is deployed in an offline environment, will crashpad continuously attempt to send crash logs during the offline period, or will it detect when the network is back online before attempting to send the crash logs?
2.If there is no network connection for an extended period and a large number of crashes occur, which are stored locally on the user's machine, is there a limit on the maximum number or size of stored crash files? Or is there any mechanism to delete old crash files from the user's local machine?
How are you getting stuck?
1.If my sentry-native is deployed in an offline environment, will crashpad continuously attempt to send crash logs during the offline period, or will it detect when the network is back online before attempting to send the crash logs?
2.If there is no network connection for an extended period and a large number of crashes occur, which are stored locally on the user's machine, is there a limit on the maximum number or size of stored crash files? Or is there any mechanism to delete old crash files from the user's local machine?
Where in the product are you?
Unknown
Link
No response
DSN
No response
Version
No response
Activity
getsantry commentedon Mar 20, 2025
Assigning to @getsentry/support for routing ⏲️
supervacuus commentedon Mar 21, 2025
With version 0.8.2, we enabled the
crashpadretry mechanism on all platforms (upstream enables this feature only for iOS). However, this only affects the sending of crashes (when using thecrashpadbackend).There is currently no mechanism in any of the Native SDK transports to attempt to guarantee delivery. If you capture any event and the network is offline, transport will discard the event once a request fails (unless this happens due to rate limiting).
There is no attempt to detect whether the network is offline/online in
crashpad, but with version0.8.2, we enabled its retry mechanism that works in the following way:crashpad_handler(typically the restart of your application) andYour events will likely be discarded even with retries if you have a long offline interval.
Besides discarding events via the retry mechanism after the five retries mentioned above, we trigger a cleanup of the
crashpaddatabase on everysentry_init(). Skipped or processed database entries will be removed if they are older than 2 days or if the entire database grows beyond 8MiB. Of course, if a particular crash dump is larger than 8MiB, it will stay on disk until the application initializes the SDK again (and the upload is successful or all retries fail).Similarly, our internal database cleans up all old runs during
sentry_init()after sending any remaining envelopes that might have persisted from the last run. There is no prune period or size boundary; if the files from a previous run were processed, they will be immediately deleted.So, as you can see, we deliberately try not to fill the disks.
We currently do not expose a mechanism that would safely delete old crash files on behalf of the user besides our automated removal on startup.
zongyangbigpolo commentedon Mar 27, 2025
really appreciate～～