Directions for offline reporting?

[danse]

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?

[mattrobenolt]

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.

[danse]

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

[mattrobenolt]

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.

[lauritzen]

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);

[cappslock]

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:

1. 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.
2. A callback/callback(s) on the captureException(),sendMessage()`, etc. methods which is/are triggered on success/failure
3. Promisifying those methods (meh)
4. Triggering events (where?) on failure and providing enough context in the event data to attempt a re-send of that event

[webberig]

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/

[oliviertassinari]

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]);
  }
}

// ... 

[cudasteve]

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?

[benvinegar]

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?

[mattrobenolt]

Design decision needed. :)

[cudasteve]

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?