retryFailedRequests resends requests with unknown status

[alex-d-jensen]

Describe the bug
When navigating between pages, and sending events on such (using pagehide, beforeunload etc), the retryFailedRequests flag of the tracker is not respected - or just doesn't behave as intended.
No status received causes resending of events, despite retryFailedRequests being set to false.

To Reproduce
2 pages, with the script below on it, looking as such:

// Minimal tracker for testing duplicate event behavior
import { newTracker, trackPageView, trackSelfDescribingEvent } from "@snowplow/browser-tracker";

// Initialize tracker
const tracker = newTracker('sp', 'localhost:9090', {
  appId: 'reprex-app',
  platform: 'web',
  cookieDomain: 'localhost',
  contexts: { webPage: true },
  bufferSize: 1,
  retryFailedRequests: false,
  retryStatusCodes: [],
  eventMethod: 'post',

});

// Event counter
var eventCounter = 0;

// Track page view on load
trackPageView();
console.log('📄 Page loaded, page view sent');

// Send exit event
function sendExitEvent() {
  eventCounter++;

  const exitEvent = {
    schema: 'iglu:com.reprex/page_exit/jsonschema/1-0-0',
    data: {
      page_url: window.location.href,
      page_title: document.title,
      exit_timestamp: new Date().toISOString(),
      event_number: eventCounter
    }
  };

  console.log('🚪 Sending exit event #' + eventCounter);
  trackSelfDescribingEvent({ event: exitEvent });
}

// Unload handlers
window.addEventListener('beforeunload', () => {
  console.log('🎯 beforeunload fired');

});

window.addEventListener('pagehide', () => {
  console.log('🎯 pagehide fired (no duplicate send)');
  sendExitEvent();
});

console.log('🔧 Tracker initialized on:', window.location.href);

And links between the two packages.

When navigating, observe that multiple events are being sent - as those that don't report back a status to the tracker are resent.

Expected behavior
I'd expected the retryFailedRequests flag to be respected, also for events without a known status.

Screenshots

These screenshots show both network tab from browser, and snowplow micro instance - the double entries of page_exit are due to events being sent twice (as the first one do not give back status in time).

Desktop (please complete the following information):

• OS: Tested on MacOS
• Browser: Only tested on chrome
• Version: Snowplow versions below:

v_tracker:string"js-4.6.5"
v_collector:string"micro-ssc-2.3.0-memorysink"
v_etl:string"snowplow-micro-2.3.0"

Additional context
I've tried with both the browser and javascript tracker, and both exhibit same behaviour.
I know events on page exit is a difficult thing - but the automatic and unconfigurable behaviour really surprised me.

[miike]

I believe this is the intended behaviour as retryFailedRequests will only allow you to toggle retrying requests that have failed rather than requests that have an unknown status (so are not successful but are also not failed).

This more conservative behaviour means that some requests are likely sent twice (but then can be easily deduplicated in enrich / downstream) versus potentially having them not sent at all and as a result missing an unknown portion of data that is never retried. Is there a particular use case you have in mind where missing the data is preferable to duplicates?

[jethron]

Yeah, retryFailedRequests and retryStatusCodes are Emitter options that configure handling the response from the collector, so shouldn't have any impact in this scenario where that isn't defined yet.

For "YOLO - don't store events locally just fire and forget"-mode, you probably want the (admittedly unintuitive) stateStorageStrategy: "cookie" setting. Since this effectively disables localStorage batching and persistence for other, perhaps more important events, you may want to toggle it in your pagehide handler or similar via the (also unintuitive for this use-case) disableAnonymousTracking method.

[alex-d-jensen]

Thank you both for your answers - I really appreciate it!

I guess it makes sense - but I had hoped for something in one of the configurable options (maybe response code 0 or 999 or something could be interpreted as "don't care about return codes"?)

@miike - In this case, we're fleshing out some custom "element in view" tracking (we're aware of the new plugin, but it sadly doesn't match our needs). Once an area is out of view, an event is sent - but if an area is in view, and the page is exited (either due to page close, or navigation, we want the current/last unfinished status as well if possible.

When testing this, we got duplicate events - quite consistently. Given that it's a somewhat high volume event (i.e. more or less at least one per page view), it would be excessive, hence the desire to suppress.
In other words - for a (sub)set of events, we would get almost 100% duplication.
In more general terms - for events sent on page exit, you will get close to 100% duplication.

@jethron - the documentation on that confused me a lot. They are documented as the superset of tracker and emitter configuration, with little separation between the two. At first, I though the setting wasn't actually passed on to/used by the emitter. That led me to test whether there was a difference between the browser and javascript tracker - there wasn't.

Could you show a brief sample of your suggestion (how to use that strategy only for this particular case)?

I guess this can be turned into a feature request/documentation improvement request - depending on your moods.

[miike]

Ah thanks Alex - that use case makes sense. The response code doesn't come back at all from the collector if it's still pending so can set a timeout on requests but this may not be exactly what you want as it may have side effects elsewhere (i.e., slow internet connections).

As you want to do this selectively for events would you consider using a Javascript plugin to do this? You could create a reasonably minimal plugin that uses the filter method to suppress any events where they are the event_name you want to suppress and the difference between the created timestamp and the current timestamp is greater than a given threshold (e.g., 30 seconds).

[alex-d-jensen]

@miike Suppress might have been the wrong word - we still want to track it, but given the fickle nature of navigation, I think we would be okay with no retrying - for those particular events.
We only want to suppress the retries - not the actual events.

As I'm reading the tracker code, plugins are applied to the tracker, not the emitter, or have I missed something?
How would that be helpful?
Besides that, we're open to almost anything.

[jethron]

Should be like your example above but with sendExitEvent changed like below.

// Send exit event
function sendExitEvent() {
  eventCounter++;

  const exitEvent = {
    schema: 'iglu:com.reprex/page_exit/jsonschema/1-0-0',
    data: {
      page_url: window.location.href,
      page_title: document.title,
      exit_timestamp: new Date().toISOString(),
      event_number: eventCounter
    }
  };

  console.log('🚪 Disabling event queue');
  disableAnonymousTracking({ // Note: if you're actually in anonymous tracking mode you probably want `enableAnonymousTracking` again instead, you want to set it to the current state if possible
    stateStorageStrategy: 'cookie' // this will change the stateStorageStrategy from the default `cookieAndLocalStorage` to just `cookie`; this disables event queuing (which relies on localStorage) for the rest of this pageview, which shouldn't matter as we're theoretically about to end it (mumble mumble back/forward cache etc)
  });

  console.log('🚪 Sending exit event #' + eventCounter);
  trackSelfDescribingEvent({ event: exitEvent }); // doesn't get added to queue, so if fails to send will be lost; if sent will not be retried on next pageview
}

(and you can ignore bufferSize, retryFailedRequests, retryStatusCodes, eventMethod and use the defaults; you can import disableAnonymousTracking/enableAnonymousTracking from @snowplow/browser-tracker along with the other methods)

I had to put the handler in beforeunload in Firefox instead of pagehide, but those sorts of browser compat issues aside, this seemed to work as I expect.