Error Date format occurs every day after midnight #20098

Expected Behavior

No error emails.

Current Behavior

I have a problem that occurs every day after midnight.
I get an email with the following error:

ERROR [2022-12-13 01:00:08] 2973587 Scheduler: Error Date format must be: YYYY-MM-DD, or 'today' or 'yesterday' or any keyword supported by the strtotime function (see http://php.net/strtotime for more information): for task 'Piwik\Plugins\CoreAdminHome\Tasks.purgeOutdatedArchives'

Yesterday another error was added:

ERROR [2022-12-12 00:00:10] 1520409 Scheduler: Error Date format must be: YYYY-MM-DD, or 'today' or 'yesterday' or any keyword supported by the strtotime function (see http://php.net/strtotime for more information): for task 'Piwik\Plugins\CoreAdminHome\Tasks.purgeOutdatedArchives'
ERROR [2022-12-12 00:00:10] 1520409 Scheduler: Error Date format must be: YYYY-MM-DD, or 'today' or 'yesterday' or any keyword supported by the strtotime function (see http://php.net/strtotime for more information): for task 'Piwik\Plugins\CoreAdminHome\Tasks.purgeOrphanedArchives'

In Matomo everything seems to work fine and in the “System Check” page there are no warnings (green light). I've also tried disabling the privacy features that purge old raw data and reports, but the problem persists.

I have configured the following cron command:
***/public_html/matomo/console core:archive --url=https://mydomain.com/matomo/ > /dev/null

I have contacted the company where the Matomo installation is hosted and they told me that everything is working fine on their side.
The problem persists even after updating to the latest version (4.13.0).

From what I read from the email it should be something related to the deletion of old archives, could it be due to the fact that the Matomo installation is recent and there is no archive to delete?

Possible Solution

I have no idea.

Steps to Reproduce (for Bugs)

I am unable to reproduce the problem.

Context

Your Environment

• Matomo Version: 4.13.0
• PHP Version: 8.0.24
• Server Operating System: Linux
• Plugins activated: API, Actions, Annotations, BulkTracking, Contents, CoreAdminHome, CoreConsole, CoreHome, CorePluginsAdmin, CoreUpdater, CoreVisualizations, CoreVue, CustomDimensions, CustomJsTracker, Dashboard, DevicePlugins, DevicesDetection, Diagnostics, Ecommerce, Events, Feedback, GeoIp2, Goals, Heartbeat, ImageGraph, Insights, Installation, Intl, IntranetMeasurable, LanguagesManager, Live, Login, Marketplace, MobileMessaging, Monolog, Morpheus, MultiSites, Overlay, PagePerformance, PrivacyManager, ProfessionalServices, Proxy, Referrers, Resolution, RssWidget, SEO, ScheduledReports, SegmentEditor, SitesManager, Tour, Transitions, TwoFactorAuth, UserCountry, UserCountryMap, UserId, UserLanguage, UsersManager, VisitFrequency, VisitTime, VisitorInterest, VisitsSummary, WebsiteMeasurable, Widgetize
• Plugins deactivated: DBStats, MobileAppMeasurable, TagManager
• Browser:
• Operating System:

Hi @Paskm92, thanks for reporting this.

I've tested the two purge archives task that reported errors for you, but I wasn't able to recreate the issue. During both these tasks the archive table name is used to build a date string, so one possibility is that there could be a misnamed archive table in your database which would then cause an invalid date error. It's probably not something to be concerned about.

If you have MySQL access for your installation and are comfy running queries then you could look at the output of SELECT table_name FROM information_schema.tables WHERE table_schema = 'YOUR_DB_NAME_HERE' AND table_name LIKE '%archive%'; to check if there are any numeric or blob tables which do not end in YYYY-MM which would confirm the cause of the issue.

If this is the case then we could improve the Matomo code here to check validity of the date derived from the table name before attempting to use it and show a more helpful message naming the offending table if it is invalid.

Hi @bx80 ! Thank you for the answer.

I ran the query you sent me and I am attaching the result in the photo. All archives respect the YYYY-MM format.

I have also opened the tables and the date format is always respected. The archive_invalidations table is empty.

@bx80

Archives from 2022_01 to 2022_10 are empty since my Matomo installation is recent. Maybe the function throws a date error since it doesn't find any data?