Note: The test changes are kind of expected. We had a couple of fixtures where ecommerce data was tracked, even though it actually wasn't enabled for that site.
For some Fixtures I have activate the ecommerce flag, while for others I kept it off on purpose. That way we can see that there are null records archived, even though some data would actually be tracked and available.
$this->getProcessor()->processDependentArchive also (only) call the goals archiver, but with a segment? It should skip doing any queries in that case as well, but create empty archives. Thought it would be good to have empty ones there as well, to ensure they won't be created later maybe.
@sgiehl AFAIK it would still try to resolve the segment because every time we process dependent archives it's also trying to resolve the number of visits we had for that segment even before we go into the goals archiver
The only way would be to initialise a new archive manually for that segment and writing empty entries and finishing the archive without even going in there
Haven't yet debugged that through, but won't those "VisitsSummary" numbers be archived by the
VisitFrequency archiver nevertheless. So it should at least be no additional "work" to do 🤔
It's something general the archiver does for any kind of archive. Even if it was a say customreports specific archive. I'm not sure if we can check for any other archives there as they may be outdated or be invalidated soon after this or something. Also would partially depend on the order in which plugins archive in the same archive etc.
@tsteur added some code to skip the dependent archives if there are no goals and ecommerce isn't used. I guess that's the simplest solution for now even though that might mean that those archives might be archived later when that changes.
@sgiehl we might need to do the same for the
processDependentArchive calls in
aggregateMultipleReports? I'm not entirely sure what Matomo does here but usual behaviour when Matomo tries to aggregate data, and it doesn't have the data for the subperiods, then it would launch the archiving for these subperiods. Aka it might try to launch the day archive for each dependent archive. I haven't double checked but wanted to check if you tested that case maybe?
@tsteur Haven't tested that. But as there won't be a done flag for that segment, I'm pretty sure the day periods would then be processed. Just pushed an update so it will be skipped as well
@sgiehl I've just done some testing what happens when previously we were archiving days/weeks/months.
Then we add a goal.
Then it goes into the aggregateMultipleReports for a week or month.
It will then launch a processDependentArchive.
It will notice there's no such archive there yet.
It will initiate a new launch of archiving for each day. The parameters are then set again to root request and
onlyArchiveRequestedPlugin is set to false meaning it will archive all plugins by the looks for that segment instead of only the goal specific one. That makes it potentially worse. It probably also means that we might sometimes launch the entire day of archiving for a dependent archive if the weeks or month being processed before a day which may be especially bad for browser archiving (in general, not just for this issue).
The call stack is quite long.
Even worse it will then launch processDependentArchive again for that day, and because
self::$ARCHIVE_DEPENDENT is not set to false, it will eg combine the returning visit with the new visit segment and archive this too.
We could probably work around it by writing empty archives somewhat similar to this when no goal is configured:
But it makes me think maybe there is a problem with processDependentArchive overall as even if the processDependentArchive launches archiving for missing periods, then it should not suddenly lose these archive process parameters
How can we make sure that we wouldn't suddenly launch archiving for all plugins in that case and to make sure we only archive data we need? or maybe there are other ideas/fixes?