-
Notifications
You must be signed in to change notification settings - Fork 239
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Duplicate customEvent entries #2205
Comments
Update: The duplicates seem to appear when the web browser is closed before the interval causes the queued data to be sent. Perhaps an issue with how it flushes with onbeforeunload? |
I think this might be related to #2195 where the You could also downgrade to v3.0.3 instead to avoid this specific issue (assuming that is the issue). |
This one is not solved in 3.0.6 as far as I can tell. I am seeing the same duplicates behavior for at least customEvents and dependencies. It is happening on close/reload and does seem to be related to "bad flushing logic", almost as if the flushing doesn't mark records as flushed and they get sent again or something along those lines. If I downgrade to version 3.0.2 it doesn't happen, if I use any version from 3.0.3 up to and including 3.0.6 there is something wrong (but perhaps different things, cause those all had minor funny issues). I am not using any (manual/own) flush in my app. It is not super easy for me to reproduce or track down sorry, but it is easy for me to find the dups in logs: |
I am experiencing a similar behavior when sending custom metrics from my app. The bug can be easily reproduced with this. Just replace the instrumentation key with your own (look for ). The source code was taken from react app insights app and changed. It is supposed to track custom metrics about the duration the page was open (see implementation of Similarly, flushing the messages with |
There are many possible reasons for duplication of events, this issue only being one of them (unfortunately). So can you try using the new ApplicationInsights-JS/channels/applicationinsights-channel-js/src/Sender.ts Lines 891 to 908 in 200884c
However, this will also cause an XHR request to be sent (during page unload) which may get cancelled by the browser and not tell use that the event sending was successful (because either the browser terminated the request or the page simply navigated away before handling the response -- so we never get told). This later case is the same as what it should have been prior to v3.0.3. You could also try completly disabling sendBeacon usage during page load (so it just goes straight to an XHR call) with setting |
@Karlie-777 can you also please re-look at this to see if we have missed something. |
for 3.0.6, try setting
in the config |
I tried 3.0.7 just now and the dup issue seems to be fixed. Thanks much for tracking this down! |
I would like to add to this that in our case, the issue is still present in version 3.0.7, but with a very specific setup: We have a dashboard solution that runs many different smaller components that each initialise their own Application Insights 'instance'. This worked perfectly in version 2.x (we've been using 2.6.3 and 2.8.9 specifically over the past years), but the flushing now appears to be not working the same as before and we see many dupes. We were using 3.0.6 when I saw the same issue as described bij the OP, so we upgraded to 3.0.7. This did fix the on-unload flushing of duplicate messages when only one component used an App Insights instance, but as soon as we add more components, the problem re-arrises and multiplies each time we add more components to the page that have their own instance. We use this code to initialise the instance: By the way, it's not just Using Fiddler to watch network traffic, I see many duplicate track events when I switch browser tabs back and forth: The green one is the one that fires normally, the red ones pop-up when I leave the browser tab. Any hints on what we could do to fix this? |
Additionally, setting |
@MarksPoint please try
|
For any of the "automatic" events (RemoteDependency (Ajax (XHR/fetch) requests) unless disabled or excluded and runtime exceptions On the flushing situation, try what @Karlie-777 has suggested as those configurations (should) be reverting back to the same operation as v2 by default (don't use |
This is mostly because the AI_sentBuffer and AI_buffer is where Application Insights "trys" to keep any unsent batched events, so that if the page crashes or navigates away when the user comes back to the page it picks up these events and sends them with the new page. If we set these to a unique prefix for every page load then it would never (or very rarely) find these old unsent / acknowledged events and send them off (leading to event loss). By using the So probably what was happening in your case (with all instances using the same empty prefix) is that on initialization all of them where / are picking up these "batched" events and re-sending them (probably because they could not be sent via the sendBeacon -- because of the limit). Not sure why v2 wasn't also doing this as I don't believe we refactored the buffering... It may be that in v2 we used a synchronous XHR request (which chrome doesn't allow anymore) during the page unload so v2 always marked them as complete -- which would have been silently dropping the events. |
Description/Screenshot
We are upgrading from v2.8.16 to v3.0.5. Since upgrading, we are seeing duplicate entries in application insights when using the trackEvent method...
Duplicates are shown here...
Steps to Reproduce
Calling the trackEvent item above causes several duplicate entries to be created.
Expected behavior
Just one entry per trackEvent call is expected.
The text was updated successfully, but these errors were encountered: