Crash events not cached when no internet connectivity

[cwarner1]

Using an Android device connected via ethernet to a ECU/Gateway.

If the Android device has a connection to a host, it can still fail to send, and the message will not be cached.

RaygunPostService.java, Line 43

        if (isPulse && hasInternet) {
          RaygunClient.postPulseMessage(apiKey, message);
        } else if (!isPulse && hasInternet) {
          RaygunClient.post(apiKey, message); // This can fail and does not end up cached
        } else if (!isPulse && !hasInternet) {
           // Caches to filesystem

currently using a work around, but may be other effects from this use case

        boolean store = !hasInternet && !isPulse;
        if (isPulse && hasInternet) {
          RaygunClient.postPulseMessage(apiKey, message);
        } else if (!isPulse && hasInternet) {
          if (RaygunClient.post(apiKey, message) == -1) store = true;
        } 
        if (store) {
            // Caches to filesystem

[TheRealAgentK]

Thanks @cwarner1.

In a nutshell, I think this would be a new feature request.

I believe the current provider was never made to cater for this. The intention had been to cache crash reports when the device is offline. If - for whatever reason - the http post fails for another reason, there was never any re-processing supposed to happen but the provider would just log an exception

@mduncan26 - Could you clarify if you'd want to extend the local storage of crash reports for cases in which the http request failed?

[cwarner1]

The effect is a bit worse than that, it deletes previously cached crash reports as well.

[TheRealAgentK]

@cwarner1 What would be your ideal scenario for this feature to work?

[cwarner1]

Ideally?

Any crash report generated by the application is cached until it can be delivered to Raygun, up to a limit of 64 (configurable?) crash reports, with the oldest crash reports discarded when the limit is exceeded.

A cached message will only be deleted from the cache if -
1 - It is successfully delivered to Raygun
2 - A new crash report has occurred and the oldest event needs to be deleted.

Delivery of cached data is attempted -
1 - On a change in network connectivity
2 - Periodically while a network connection is present
3 - When a new crash report occurs and a network connection is present

[mduncan26]

Hi @cwarner1

Just a quick explanation around the caching. We have found issues with our current implementation and unexpected results occur because of this. It was not implemented well and I am sorry for the inconvenience. We are addressing these problems in the new 4.0 release of the provider which is currently being worked on. We plan to have it so the oldest messages are kept until they can be sent. The reason behind this is we do not wish to delete an initial report that would then be pushed out by another that has been recorded multiple times.

We are looking to have the max number of reports stored on device configurable in the 4.0 release of the provider. However we will be keeping 64 as the upper number of reports allowed on the device.

In terms of when to deliver crash reports, the current implementation attempts to do so each time a new report is sent. We plan also to have it post stored reports when the client is first initialised on start up in the new 4.0 release of the provider.