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
Regression: some daily reports disappear from UI, and weekly reports are corrupted #17428
Comments
Hi @nelhefni, thanks for the detailed report. Partial archives are meant to be included in the entire list of all idarchives to look through. We don't select only one archive, but the latest DONE_OK or DONE_INVALIDATED archive, then all DONE_PARTIAL archives that are later. We then look for data in all of those archives. Using this knowledge, can you take another look? Or if possible can you provide access so we can take a closer look? |
Hi @diosmosis, thanks for the fast answer. matomo/core/DataAccess/ArchiveSelector.php Line 198 in 2c30dc8
As there is only one element in matomo/core/DataAccess/ArchiveSelector.php Line 202 in 2c30dc8
then, matomo/core/DataAccess/ArchiveSelector.php Line 206 in 2c30dc8
then we matomo/core/DataAccess/ArchiveSelector.php Line 212 in 2c30dc8
finally, we have only one Line 638 in 2c30dc8
|
@nelhefni thanks again for the detailed post. That code looks broken but it's actually working correctly, the problem is that archives like Can you see what reports are in 56405 (eg, what names are in the blob table for 56405)? I think we can put in some code making sure partial archives are never saved w/ that done flag, and modify the code you reference just in case this edge case happens in some other way, but I can't think of how this might happen. |
@diosmosis thanks for the input, the issue could then be a side effect of #17434 Here are the reports for
Which doesn't include myPlugin |
@nelhefni the Goals plugin doesn't have any logic to rearchive in the past when it changes: https://github.com/matomo-org/matomo/blob/4.x-dev/plugins/Goals/API.php#L198-L232. The funnels plugin does, which is connected, but then I would expect to see Funnels reports in this table. Can you try editing a goal or creating a goal, then checking what gets added to archive_invalidations (then truncate the table or take note of the max idinvalidation and delete everything greater than it to avoid launching any archiving)? Based on the archive contents above it seems like that archive should have a done value of |
@diosmosis I did update the funnel attached to one of my goals.
Then, when the cron job started, the invalidation process added a lot of new rows to the archive_invalidations table:
This seems to make sense, as we have 3 segments, and go back to March 1st because of the following setting: Moreover, If I look for the corresponding idarchive in matomo_archive_numeric_2021_**, I find only one row:
I'm not sure to understand the purpose of this Also, I deleted manually all the rows for period 3, as I want to avoid the issue described here: #17434,
but then some more got added during the archiving process:
And those rows keep coming back. This is probably due to the invalidation cascading. |
Hi @nelhefni, I'll add context to your investigation below:
This is expected, we remove pending invalidations for the old funnel ID.
So far, still expected: when we edit the funnel, we add the information to rearchive to list in the option table, core:archive will look at that list before archiving a site and create invalidations. We do this so the request to edit a funnel doesn't slow down due to inserting invalidations.
The idarchive is just a diagnostic, the code doesn't use it. It's set to the existing latest idarchive w/ the same parameters in case we want to know which previous idarchive the invalidation is meant to replace. If it's NULL, it would mean there wasn't one.
So the archive in question is one of the old ones that are meant to be replaced. I'm not sure exactly what you're asking for, so I'll explain but feel free to ask if there's more information you want. The "done flag" of an archive tells us a couple things:
This was also a partial archive and should not have been set to
That's odd, they shouldn't come back if you remove them from the invalidations table. Can you check the contents of the |
@diosmosis thanks for the explanation Here is the content of the
|
Hi @nelhefni, thanks for going through the trouble of investigating this issue so thoroughly! I was able to track down the root causes of the two issues identified so far:
They will hopefully be ready to test or merge soon. I'm still not sure about the Funnel invalidations reoccurring, though. If you continue to see this, it might help to add a warning log in |
thanks @diosmosis ! |
@nelhefni both of the PRs have been merged, would you be able to see if they solve the problem for your? |
Assuming this was all fixed in 4.3 as we're no issues so far. I'll close this. |
Hello,
We think PR #17216 has introduced some regressions to the archiving process since Matomo 4.2.0
FYI, browser archiving is disabled:
For a given plugin, we are facing 2 issues since the update to Matomo 4.2.0,
delete_reports_enable
is set to 0This seems to be related to the changes made with the handling of partial archives.
Indeed, we have a lot of partial archives in our DB, which doesn't contain the reports of our impacted plugins:
As you can see,
myPlugin
report is not part ofpartial archive
56405 (partial
because the value ofdone
row is 5), but it is nevertheless selected since Matomo 4.2.0, asts_archived
is more recent.Since #17216,
checkAuthorizedToArchive = false
is passed toRules::getSelectableDoneFlagValues
during the retrival of archive to display in the UImatomo/core/DataAccess/ArchiveSelector.php
Line 370 in 2c30dc8
As a consequence, both
ArchiveWriter::DONE_PARTIAL
andArchiveWriter::DONE_INVALIDATED
are added to the list of accepted value. Which explains why archive 56405 is selected instead of 46176 in our case.matomo/core/ArchiveProcessor/Rules.php
Line 321 in 2c30dc8
Thus, as soon as archive 56405 was created,
myPlugin
report disappeared from the UI.I don't think
ArchiveWriter::DONE_PARTIAL
should be part of the list of accepted values.We have been able to fix this issue#1 with this PR #17425
Concerning issue#2, we have been able to fix it by reverting the changes done in the same PR to
ArchiveSelector::findArchiveDataWithLatestTsArchived
, and then invalidating faulty reports and re-running the cron job.Your Environment
Matomo 4.2.1
The text was updated successfully, but these errors were encountered: