@jbrule opened this Issue on July 19th 2021

Upgraded from 3.13.6 -> 4.3.1

I recently upgraded to 4.3.1 and most things are working well. I am however getting the following error when querying monthly Time states for some sites. FYI. The the initial archive after upgrade is still running (via cron). Other sites works for this particular time frame. Any tips?

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):

I see some NULL visitor_localtime entries in my log_visit table but it is not consistent as those sites doesn't error out when retrieving the report

Matomo-4 3 1 Error
Matomo Diagnostics

@jbrule commented on July 19th 2021

This is in the logs

ERROR CoreHome[2021-07-19 17:49:54 UTC] [591e0] Failed to get data from API: /apps/apache/www/production/matomo/core/Date.php(1126): 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):
WARNING CoreHome[2021-07-19 18:56:16 UTC] [3b902] /apps/apache/www/production/matomo/plugins/VisitTime/functions.php(18): Warning - mktime() expects parameter 1 to be integer, string given - Matomo 4.3.1 - Please report this message in the Matomo forums: https://forum.matomo.org (please do a search first as it might have been reported already) [internal function]: Piwik\ErrorHandler::errorHandler(),<a href='/1'>#1</a>/plugins/VisitTime/functions.php(18),<a href='/3'>#3</a>/core/DataTable/Filter/ColumnCallbackReplace.php(96),<a href='/4'>#4</a>/core/DataTable.php(528),<a href='/5'>#5</a>/core/DataTable.php(613),<a href='/6'>#6</a>/core/API/DataTablePostProcessor.php(303),<a href='/7'>#7</a>/core/API/DataTablePostProcessor.php(133),<a href='/8'>#8</a>/core/Plugin/Visualization.php(536),<a href='/9'>#9</a>/core/Plugin/Visualization.php(193)
@diosmosis commented on July 20th 2021 Member

Hi @jbrule can you apply this PR: https://github.com/matomo-org/matomo/compare/17796-debugging?expand=1 and trigger the error again? It will hopefully provide some more details.

@jbrule commented on July 20th 2021
unable to parse date label:

matomo-parse-label

@diosmosis commented on July 20th 2021 Member

@jbrule I'm not sure why the label is empty there, they should be predefined... I've updated the branch: https://github.com/matomo-org/matomo/compare/17796-debugging?expand=1 . Can you apply the changes then post a screenshot of the report that is created (preferably in the table view)?

@jbrule commented on July 20th 2021

matomo-time-table

@diosmosis commented on July 20th 2021 Member

@jbrule looks like you've got a visit with no local time data... can you check the log_visit table for a visit where visitor_localtime IS NULL AND idsite = ? AND visit_last_action_time >= ? AND visit_last_action_time < ? substituting the idSite and start and end time for the period you're looking at? For example:

SELECT * FROM log_visit WHERE visitor_localtime IS NULL AND idsite = 1 AND visit_last_action_time >= '2021-06-20 00:00:00' AND visit_last_action_time < '2021-06-21 00:00:00';
@jbrule commented on July 21st 2021

SELECT COUNT(*) FROM piwik_log_visit WHERE visitor_localtime IS NULL
5886

@diosmosis commented on July 21st 2021 Member

@jbrule I've created a PR to handle the NULL values you're having: https://github.com/matomo-org/matomo/pull/17801 . But you may want to look into why there are NULL values there, as the PHP tracker code doesn't allow the column to be NULL.

@jbrule commented on July 21st 2021

Looks like these happened around the time of upgrade. It's a pretty small number of the whole so I'm just going to purge them and invalidate the archive for the day.

@jbrule commented on July 21st 2021

I neglected to disabled Redis Queue processing and some went through. I intended for everything to queue up in Redis until DB schema update was complete.

@tsteur commented on July 21st 2021 Member

@jbrule does this mean the issue is resolved now?

@jbrule commented on July 21st 2021

@jbrule does this mean the issue is resolved now?

Yes

@tsteur commented on July 21st 2021 Member

great, thanks for letting us know.

This Issue was closed on July 21st 2021
Powered by GitHub Issue Mirror