Directions for offline reporting?

Hi, we have a web app with offline capabilities deployed, and it would be great to use Sentry for the application monitoring. We already use it for our back end and it works great!

Unfortunately i don't see support in raven js for this, so i think that we would be forced to roll out our own solution. Can you confirm this? What would be your suggestions about how to proceed? Would you recommend trying to reuse some logic from raven js?

Can you detect if the user is offline?

If so, it wouldn't be impossible to collect events and queue them up. When the user gets back online, send them through Raven.captureException again.

I can probably help with how that'd work or add a hook in to help this.

Great, thanks for the collaboration. I could detect the user being online even just testing Sentry reachability. For this i could listen the transmission failure events, but then how to retry?

About using captureException, that would be fine, but i would like to keep the excellent handler raven provides for unhandled exceptions. I would need to add some middle logic between raven error detection and error transmission

Yeah, lemme think about this. I think there's a nice way that we can either just support this automatically in raven-js, or provide a hook to do it. I think that's fair.

I'm looking for the same funtionality as well. After examining the docs it seems that a work around could be to use shouldSendCallback, something like this:

shouldSendCallback: function(data) {
  localStorage['queued-errors'] = (localStorage['queued-errors'] || []).push(data);
  return false;
}

And then listen for network connectivity and process the queue using Raven.captureException:

window.addEventListener('online', checkAndProcessQueue);

This is piggybacking a bit, but I have a similar issue. We can't report errors when the client loses connection to the host (though they are not necessarily offline). Trolling around, I see that there's a ravenFailure event being triggered on the window, but I can't get enough data from this event to accomplish what I'm trying to do: retry sending the error on failure.

I see a few possible approaches to this:

A per-instance or per-message retry option, which might specify how often to retry sending events, how many times to try before giving up, etc.
A callback/callback(s) on the captureException(),sendMessage()`, etc. methods which is/are triggered on success/failure
Promisifying those methods (meh)
Triggering events (where?) on failure and providing enough context in the event data to attempt a re-send of that event

You should probably have an offline storage facility so the error messages can be sent later in time. Possibly even after the user closes the app and later reopens it while online. Similar to an "offline first" approach:
http://offlinefirst.org/

I have faced the same issue. At first, I wanted to solve it similarly to how I'm solving the offline google-analytics issue with a service worker. The approach is well explained by Google here.

However, when targeting Cordova, Service Worker might not be available.
And a hacky solution is needed. I have came up with this one:

https://gist.github.com/oliviertassinari/73389727fe58373eef7b63d2d2c5ce5d

import raven from 'raven-js';
import config from 'config';

const SENTRY_DSN = 'https://XXXX@app.getsentry.com/YYYY';

function sendQueue() {
  const sentryOffline = JSON.parse(window.localStorage.sentryOffline);

  if (sentryOffline.length > 0) {
    raven._send(sentryOffline[0]);
  }
}

// ...

@webberig

I agree with @webberig. I was actually a little surprised this wasn't already part of raven since it's pretty impressive in a lot of other cool ways. Depending on an app's architecture, there could potentially be a non-trivial percentage of the errors that are the RESULT of being offline. Being able to report on those is pretty critical in a lot of implementations.

So my vote is that this should be baked in and automatic. When there's an error sending the message to sentry, the message should be stored and tried again later (either on a timer, on an event, or even just on the next message transmission if you want to keep it simple).

Also, what's the "DDN" label mean?

@mattrobenolt

I was actually a little surprised this wasn't already part of raven since it's pretty impressive in a lot of other cool ways. Depending on an app's architecture, there could potentially be a non-trivial percentage of the errors that are the RESULT of being offline.

Totally fair. But I'm not sure it should be done by default. There are many scenarios where, if a script doesn't load, the app isn't going to work no matter what. And I would say most apps just straight-up don't work offline, and don't expect to. Whether that's good practice or not is another thing.

It's sort of why we don't log AJAX errors by default, even though a good chunk of Raven users have written code to do so. But we'll try to make it easy to do so if you want. And I'd like to do the same thing here.

Also, what's the "DDN" label mean?

Not sure. @mattrobenolt?

Design decision needed. :)

I'm not sure it should be done by default.

Ya that makes sense.

But we'll try to make it easy to do so if you want. And I'd like to do the same thing here.

So, in the interest of helping make a design decision, here's some thoughts:

If I'm understanding the docs correctly, the transport config option allows one to basically take control of the last part of the pipeline where Sentry sends the data to the server and become responsible for making that transmission happen. In that case, that seems like the best place to plugin an offline queue. Instead of sending the data to the server, send it to a queue that uploads to the server in the background. That would be if someone were writing their own code to make it happen.

In a similar vein, would it be simple enough to also expose a config option (includeOffline?) that would replace the default HTTP transport with an official Raven-rolled offline-capable queue?

For browser compatibility, maybe store the queue in localStorage and have it check for connection on a timeout.
For better performance and stability, maybe leverage service workers to manage the queue so errors could even be uploaded after the page is closed. But is it a little presumptuous for a utility library to be spinning up its own service workers at this point?

has this functionality now been built in somehow to raven?

@Freundschaft

@Freundschaft No, not yet. As I understand it, for now you'll have to override the transport option or use the shouldSendCallback to build a queue for sending later.

@cudasteve

@cudasteve thanks!
someone got a working sample implementation? if not I'll try to write one and post it here

+1

Our solution:

Pass `shouldSendCallback` to Raven init

If there is no connection, out logStorageService will save the event's data

var options = {
    ...
    shouldSendCallback: function(data) {
        if (connectionStatus.check() && Raven.isSetup()) {
            return true;
        } else {
            // store log data somewhere
            logStorageService.set(data);
            return false;
        }
    }
    ...
};

Raven.config(SENTRY_KEY, options).install();

Queue trying to send logs

Queue fires this code every 25 seconds, eventually delivering all of the events to Sentry

queue.enqueue(function () {
                    logStorageService
                        .getKeys()
                        .then(function (keys) {
                            if (keys && keys[0]) {
                                logStorageService
                                    .get(keys[0])
                                    .then(function (log) {
                                        Raven.captureMessage('', log);
                                        logStorageService.remove(keys[0]);
                                    });
                            }
                            ...
                        });
                });

Has this feature been added to the library yet.

I ran into a need for this today as I have an offline capable feature. I store all my own data using indexdb but it would be nice to have an out of the box offline functionality for Sentry. If it it could use it's own local database to store events and periodically/on network changes attempt to send and clear out the db that would be super useful.

Addressed here #1165

Add an offline integration for offline errors

Add an integration for offline errors

If I do store exceptions for sending later when I come online, is there a way for me to set the timestamp on the exceptions to indicate that they didn't happen now when I'm sending them to sentry, but at some point in the past? I guess I could just add it in the extra, but it would be nice to be able to set the actual timestamp.

I don't see any such option in captureException

Navigation Menu

Repository navigation

Directions for offline reporting? #279

3 remaining items

Pass `shouldSendCallback` to Raven init

Queue trying to send logs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Directions for offline reporting? #279

Description

Activity

mattrobenolt commented on Oct 31, 2014

danse commented on Oct 31, 2014

mattrobenolt commented on Oct 31, 2014

lauritzen commented on Jan 3, 2015

cappslock commented on Sep 25, 2015

webberig commented on May 18, 2016

oliviertassinari commented on Jun 27, 2016

cudasteve commented on Jun 27, 2016

benvinegar commented on Jun 27, 2016

mattrobenolt commented on Jun 27, 2016

cudasteve commented on Jun 29, 2016

Freundschaft commented on Jul 27, 2016

cudasteve commented on Jul 27, 2016

Freundschaft commented on Jul 27, 2016

3 remaining items

peresbruno commented on Sep 29, 2016

ddddm commented on Sep 30, 2016

Pass shouldSendCallback to Raven init

Queue trying to send logs

panbhag commented on May 18, 2017

alexcroox commented on Nov 17, 2017

kamilogorek commented on Jan 18, 2018

nbrustein commented on May 14, 2020

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Pass `shouldSendCallback` to Raven init