Hi @danielpradilla any chance the plugin queued tracking is enabled on the environment with large amount of visits?

Hi @tsteur it is!

Thanks @danielpradilla that was the only way I could think of out of the box how this might happen. I now had a quick look at the code but it's not obvious yet to me how this might happen.

Could you check in Administration -> General Settings under Queued Tracking if the setting "process during tracking request" is enabled maybe?

I suppose queued tracking is always enabled or does it sometimes get deactivated?

Also are you using the JavaScript tracker to track a website?

Hi @tsteur it’s always enabled. I’ve never touched it. I’m using the JS tracker.

@danielpradilla any chance you could check regarding the other setting I mentioned?

@tsteur apologies, i meant that both queued and process during tracking request are enabled. I will experiment turning queued tracking off.

Thanks. Any chance you know roughly how often that happens? Does this happen randomly rather often or quite rarely?

Note: If I had to guess I would say that we should maybe make a copy of a RequestSet and all includes requests in https://github.com/matomo-org/plugin-QueuedTracking/blob/4.0.1/Queue/Processor/Handler.php#L46 so if the requests will be retried, then we wouldn't manipulate it again. So my theory is that rarely maybe a request fails for some reason and then it retries the requests and it basically modifies the same requestset again.

It happens quite a lot. About half of the logged-in visits are affected. Randomly. It's not tied to a particular visitor.

Thanks @danielpradilla

Are you familiar with applying patches? Could you try to apply this patch https://github.com/matomo-org/plugin-QueuedTracking/compare/4.x-dev...qt141?quick_pull=1 in plugins/QueuedTracking/Queue/Processor/Handler.php and see if this maybe fixes the issue?

@danielpradilla have you had a chance to give this a try maybe?