Library drops events that are emitted close in time to one another

[meltzerj]

Because the push function has a setTimeout, if a bunch of messages are queued, the data variable will get overridden.

Even if you wrap the setTimeout inside of a self invoking function and locally scope the data variable, I'm still getting some messages dropped. Could this be that we need to wait for the image's request to receive a response before sending the next message?

[meltzerj]

Just realized that what I said doesn't make sense, since the push function scopes data already.

[hyunlim]

@meltzerj Were the events dropped on Friday or Saturday? We had a fire on those days, and events from those days are being recovered and indexed right now.

[meltzerj]

It was last night, so Sunday night. I noticed if I take out the setTimeout in the push function, I didn't lose the events. It might be a problem with Chrome, since I was setting a breakpoint inside of the setTimeout and it wasn't firing all setTimeouts, but that's probably unlikely...

[hyunlim]

Ah, I see. The default implementation is with setTimeout, so the tracking will not block your program function stack. If you do navigate away from the page before your program's function stack is complete, the queued setTimeout's will never be reached. For example, if this was bound on a click event where window.location was switched. The function would never execute then.

Perhaps the blocking/nonblocking should be a configurable option. I'll keep this in mind for the next iteration. For now, if it's ok for the tracker to be a blocking call, do take out the setTimeout as you already did.

[meltzerj]

That would make sense. Although I think some set timeouts were not firing, even when I wasn't navigating away from pages. But I'm really not sure how that's even possible... maybe I was just seeing things.