An archive invalidation is never removed even though the data is being archived for the period regularly #19338
Labels
Bug
For errors / faults / flaws / inconsistencies etc.
Milestone
On the cloud we have a monitoring active that we're emailed should archive invalidations for some reason not be processed within a given amount of days to make sure data is always available etc.
We're receiving emails regularly especially from one account where we have for example this invalidation:
However, we can see that there is indeed an archive for this period, and the data is available in the UI.
We would have therefore expected this invalidation to be removed by the system at some point. Or we would have expected it wouldn't schedule a new archive invalidation because one already exists and then next time it would process and remove this old archive invalidation.
The referenced segment exists and is not deleted. The referenced site also still exists. And the archive has data.
Segment info:
I ran
core:archive
with-vvv
to get debug log output and this is what's happening:Meaning Matomo might only remove this entry after this year is completed maybe meaning it might only delete it in 2023-01-01? This would mean though that this invalidation will never be removed. The same seems to be happening for the monthly archive:
And it would only be removed by the beginning of the next month. It kind of defeats the purpose a bit and it's this way not clear if the system has a problem or not.
Interestingly, this same behaviour is not happening in other accounts and couldn't find any such similarly old entries. There they were deleted somehow correctly.
As a result, we're receiving emails daily about this error. We could now just remove this invalidation manually. However, next time this happens again the devops team will spend hours again troubleshooting what's happening together with core and plugin team members.
This is happening with latest Matomo (4.10) and PHP 8.
cc @JasonMortonNZ
The text was updated successfully, but these errors were encountered: