Can't get Offline integration to work

[mrmckeb]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• Provide a link to the affected event from your Sentry account

Package + Version

• @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other:

Version:

All packages at

"@sentry/browser": "^5.27.3",
"@sentry/integrations": "^5.27.3",
"@sentry/node": "^5.27.3",
"@sentry/tracing": "^5.27.3",
"@sentry/webpack-plugin": "^1.13.0",

Description

When testing Sentry for offline support, we've found that any errors that we capture offline are never sent upon reconnection.

I can see in the Network tab in DevTools that sentry sends the initial data, then when I go offline, cause an error (because the app is offline) and then go online, the error is never sent.

That same error handler can be triggered by blocking the same request in DevTools (when online) and Sentry immediately reports the error.

If I perform these as a series of actions, I can see in the breadcrumbs where the offline error is thrown (there's even a console.error there) but Sentry's breadcrumbs don't show the exception.

I can provide links privately and I'm happy to get on a Meet/Zoom/etc call to pair on this and demonstrate the issue.

[mrmckeb]

It seems like there's an error being thrown in localForage:

[rodolfoBee]

Thank you for the feedback, the Offline integration is still a WIP.

[piohhmy]

Hi there 👋 . Any update on official support/docs for Offline integration?

[lukegardiner]

Please support this. Very simple to build a queue and persist it into some browser storage...

[fritz-c]

I'm not sure if this ticket was facing the same problem, but I discovered there's an inherent conflict with the included-by-default Dedupe integration that will cause single errors cached while offline to disappear once back online. I found this by turning on debug in the init options and observing where the events were disappearing.

My understanding of the issue:
An event is created while offline. Dedupe sees it and marks it as the last seen event. The event makes its way through the other integrations until it reaches the Offline integration. Since the network is offline, Offline will cache the event until later. When the app is back online, Offline will re-capture the event, sending it back through the integrations again. Once it reaches Dedupe again, Dedupe sees the event as identical to the one that just went through it the last time around, and drops it, never to be sent by Sentry.

One caveat that made debugging a real hassle: if more than one event is captured while online, either none of the events or one of the events may disappear, as the localforage library used in Offline provides no guarantee of order preservation, so if the last event seen while offline is the first event up to be iterated through in Offline, it may get filtered out by Dedupe.

Anyway, putting Dedupe somewhere after Offline will fix it. This did it for me:

Sentry.init({
  ...sharedConfig,

  integrations: (integrations) => {
    const integrationsMinusDedupe = integrations.concat();
    const dedupeIndex = integrations.findIndex((i) => i.name === "Dedupe");
    const dedupeInAnArray =
      dedupeIndex >= 0 ? integrationsMinusDedupe.splice(dedupeIndex, 1) : [];

    return [
      ...integrationsMinusDedupe,
      new OfflineIntegration({ maxStoredEvents: 30 }),
      ...dedupeInAnArray,
    ];
  },
});

[timfish]

I think we should replace the Offline Integration with a transport wrapper that adds offline caching to any existing transport. This is roughly how the offline transport works for Electron.