[Bug] Switching from browser to cronjob archiving can break reports

[mneudert]

What happened?

When switching from browser archiving to cronjob archiving, it can happen that after an invalidation the blob archivers for some reports are created as empty. This will display "no data available" for reports, even if archiving was completed successfully and created the numeric archives.

What should happen?

Switching from browser to cronjob archiving should not create empty reports.

Rearchiving everything (complete weeks/months/years, all periods) can fix those issues but should not be required.

How can this be reproduced?

The reproduction can probably be reduced, or also run for the week instead of month, but for the sake of reproduction these worked for both 5.2.2 and 4.15.2 without changes.

1. activate browser archiving in "System > General Settings" (also configure browser_archiving_disabled_enforce=0)
2. generate data for 2024-12
3. create a new segment
4. open "Visitors > Overview" for the segment
   4.1. display both 2024-12-31 and 2024-12-30 to archive all single days of the month
   4.2. switch to the week starting on 2024-12-30 to generate week archives for the month
   4.3. switch to the month
5. deactivate browser archiving (also configure browser_archiving_disabled_enforce=1)
6. open "Behaviour > Pages" for 2024-12 (still viewing the segment)

At this step the browser archived reports should be reused and data should be displayed.

7. invalidate the month archive for the segment:

   ./console core:invalidate-report-data --dates=2024-12-01,2024-12-31 --periods=month --segment=1
   

8. run archiving for the month

   ./console core:archive --force-date-range=2024-12-01,2024-12-31
   

Archiing should finish and mention the segment being archived:

INFO [2025-01-30 16:49:11] 3120 Archived website id 1, period = month, date = 2024-12-01, segment = 'continentCode==eur', 167 visits found. Time elapsed: 0.623s

9. reopen "Behaviour > Pages" for 2024-12 having the segment selected

The report should now display the "no data" message.

And the database should display entries like these:

MariaDB [db]> SELECT * FROM matomo_archive_numeric_2024_12 WHERE name LIKE 'donebe90051048558489e1d62f4245a6dc65%' AND period = 3 ORDER BY date1;
+-----------+------------------------------------------------------+--------+------------+------------+--------+---------------------+-------+
| idarchive | name                                                 | idsite | date1      | date2      | period | ts_archived         | value |
+-----------+------------------------------------------------------+--------+------------+------------+--------+---------------------+-------+
|       567 | donebe90051048558489e1d62f4245a6dc65                 |      1 | 2024-12-01 | 2024-12-31 |      3 | 2025-01-30 16:49:11 |     1 |
+-----------+------------------------------------------------------+--------+------------+------------+--------+---------------------+-------+

MariaDB [db]> SELECT idarchive, name, LENGTH(HEX(value)) FROM matomo_archive_blob_2024_12 WHERE idarchive = 567 AND name LIKE 'Actions%';
+-----------+------------------------------------+--------------------+
| idarchive | name                               | LENGTH(HEX(value)) |
+-----------+------------------------------------+--------------------+
|       567 | Actions_actions                    |                 28 |
|       567 | Actions_actions_url                |                 28 |
|       567 | Actions_downloads                  |                 28 |
|       567 | Actions_outlink                    |                 28 |
|       567 | Actions_sitesearch                 |                 28 |
|       567 | Actions_SiteSearchCategories       |                 28 |
+-----------+------------------------------------+--------------------+

Having a hex length of 28 means it will decompress/decode to an empty array, matching the missing data in the frontend.

Matomo version

5.2.2 + 4.15.2

PHP version

No response

Server operating system

No response

What browsers are you seeing the problem on?

No response

Computer operating system

No response

Relevant log output

Validations

• Read our Contributing Guidelines.
• Follow our Security Policy.
• Check that there isn't already an issue that reports the same bug to avoid creating duplicates.
• The provided steps to reproduce is a minimal reproducible of the Bug.