@tsteur opened this Issue on July 1st 2021 Member

You can reproduce it this way:

It doesn't happen when I apply below change:

diff --git a/core/Notification/Manager.php b/core/Notification/Manager.php
index a621f27bfd..789e71a7c3 100644
--- a/core/Notification/Manager.php
+++ b/core/Notification/Manager.php
@@ -182,6 +182,7 @@ class Manager

     private static function isSessionEnabled()
     {
+        return false;
         return Session::isWritable() && Session::isReadable();
     }

Background: The requests on this page currently trigger notifications Trying to add two strings in DataTable\Row::sumRowArray... this is why this can't be reproduced on other cases.

I'm thinking this might be a regression from either https://github.com/matomo-org/matomo/pull/17413/files#diff-45b10ec69da2f6ebcecbfef283c2a608427a37f0f4790d0813fc4892894247d5R773 or maybe https://github.com/matomo-org/matomo/commit/ba6be4072538eaf54625ebfcead626107836c818#diff-943fba627b25c62a3fb10c11ee813fce6f225f90f85d1317f05ab07bbfba3e52R524 or some other change. Possible though that this has been an issue for longer and only happens when a big number of notifications are stored or so.

@diosmosis commented on July 5th 2021 Member

Some things I noticed:

  • the session data simply doesn't exist when the error occurs (it's not in the database, and $_SESSION is empty)
  • before the row evolution popover is opened, the session will exist in the DB
  • after the row evolution popover shows up, one or more of the requests triggers the destruction of the session. I'm not sure if it's done in PHP or some other strange error
@diosmosis commented on July 5th 2021 Member

More things:

  • the session is destroyed after it is failed to be read
  • it fails to read because the length of the data is likely cut off, either when it is saved or read. I could only see it try to read 65535, not write it. This is the max length of a TEXT column, so the serialize would fail causing the session to be incorrectly read.
@tsteur commented on July 8th 2021 Member

just fyi I fixed the bug that causes the notices to happen in the first place on demo2 (in the plugin). should we need to reproduce the issue there again let me know and I can apply the bug again.

This Issue was closed on August 12th 2021
Powered by GitHub Issue Mirror