We are seeing issues issues with archiving recently.
ERROR [2024-06-17 08:17:52] 4322 Got invalid response from API request: ?module=API&method=CoreAdminHome.archiveReports&idSite=1&period=month&date=2024-06-01&format=json&segment=dimension4%3D%3Dfalse&trigger=archivephp. The response was empty. This usually means a server error. A solution to this error is generally to increase the value of ‘memory_limit’ in your php.ini file. For more information and the error message please check in your PHP CLI error log file. As this core:archive command triggers PHP processes over the CLI, you can find where PHP CLI logs are stored by running this command: php -i | grep error_log
When I check the PHP error logs, I see that there is an issue like:
[17-Jun-2024 08:08:48 UTC] Error in Matomo (tracker): Error query: Error query: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column ‘name’ at row 1 In query: INSERT INTO matomo_log_action (name, hash, type, url_prefix) VALUES (?,CRC32(?),?,?) Parameters: array ( 0 => ‘VERY_LONG_PATH’, 1 => ‘VERY_LONG_PATH’, 2 => 12, 3 => NULL, ) In query: INSERT INTO matomo_log_action (name, hash, type, url_prefix) VALUES (?,CRC32(?),?,?) Parameters: array ( 0 => ‘VERY_LONG_PATH’, 1 => ‘VERY_LONG_PATH’, 2 => 12, 3 => NULL, )
For clarification the VERY_LONG_PATH in this case is about 6.5k characters, but in some cases users might have even longer URL paths.
System info:
Matomo version: 5.1.0
MySQL version: 10.11.6-MariaDB
PHP version: 8.2.20
We tried increasing the memory_limit, so I am not sure if it is actually related to the memory limit. The error messages about the tracking urls hint to me that the actual issue might be the very long action logs?
I am wondering, can we either increase the field size in the DB or remove these problematic entries somehow? Wouldn’t it be possible to automatically shorten values before the overflow like this?
How can we fix our archiving?