Offline support?

[machty]

It seems there's no support for enqueuing notifications for later when the app is offline. Is there any plan to add this in the future?

[jmshal]

How exactly would that work? And how would that relate to JavaScript errors?

[machty]

Client-side analytics platforms (one example being Localytics) often have error handling on their uploads, such that if the upload fails, it's saved for a later upload in localStorage (but perhaps just storing in memory is all we need). Then at some point in the future, it tries to send a batch of all prior unsent payloads. Bugsnag could adopt a similar approach.

It seems like an important feature just because, without it, you're losing data on any exceptions thrown if the user has a flaky connection at the time of the exception (mobile apps are particularly prone to this).

[jmshal]

I see what you mean. To be honest I'd find it unlikely to be implemented into the library itself, but I like the idea. It would seem that it's something that can be implemented on a per-app basis, based on your own specifications. Having such a system would add additional 'bloat' to the existing js file, for something that would probably be an opt-in feature anyway.

Just my opinion, sorry. But I'd never thought about it before now. Very smart.

[codepunkt]

For me, this is actually very important. Do any other Bugtracking Services support this for JavaScript-based Errors?

[abrbhat]

This will also enable an easier integration with Cordova/Ionic applications

[foxyblocks]

Notable: https://developers.google.com/web/updates/2015/12/background-sync

[jmshal]

So I've put together some code for supporting in-memory error event retrying. There are a few of things to note, which need some feedback (cc @wordofchristian @kattrali).

• Right now, the notify.bugsnag.com/js endpoint responds with an empty response. Meaning the onerror event on the Image object (when using the default notifyHandler) is fired instead of the onload event (because a zero byte image isn't valid).
  • This would need to be changed so we can retry requests for users with flakey connections, where they do have "online capability", but no actual connectivity.
  • XHR doesn't have this issue, as you can extract the response status from the XHR object, and determine whether the request was successful or not.
• I still have yet to implement support for IE8, which does have online/offline events & support, but triggers events off the document.body rather than window.
• There is currently no limit on how many events can be queued in-memory. Do you reckon it's worth adding one? If so, how large/should it be configurable?

[jmshal]

So, just an update, my PR now includes support for using sessionStorage/localStorage for storing the errors to be sent at a later time. I still need to do some more testing (for bugs and browser support), but I'd love to get some feedback on this 😄

cc @kattrali

[ghost]

There's actually a huge bug I found this week that renders our servers useless if it accidentally goes offline. This would definitely solve that.

https://github.com/bugsnag/bugsnag-js/issues/628

[mathiasrw]

Can we please find a way to store reports / breadcrumb and send them when the user gets online again?

[abigailbramble]

Hi @mathiasrw - yes this is something that we are looking into and hope to implement in a future release :)

[wojtiku]

Did this get released? Would need this as well!

[xljones]

Hey @wojtiku, this isn't something that's released yet. We'll keep you posted in this thread with any updates, but at the moment I don't have an ETA for this.

[cqcmdwym]

Hey, is there any update on this? Thanks.

[luke-belton]

Hi @cqcmdwym - this is still something on our backlog, and I don't have a firm ETA at the moment. As Xander said above we'll notify this thread as soon as there's any update.

[cqcmdwym]

@luke-belton great, looking forward to it.