Item12384: Logger issues causes statistics crash.

There are a couple of issues.

• The new logger API doesn't set a Web.Topic name if omitted from the log call.
• Statistics crashes if Web.Topic is undefined.
• Register logs malformed "Web.Topic(user) - 1" when allowLoginName is permitted.
• log calls that build the "extra" field should use named fields, and leave it to the logger to concatenate them into $extra if it doesn't have a defined disposition.

Logger should set a default Web.Topic if available, statistics should skip records with missing Web.Topic, and Register should log extra data into the "Extra" field, not into the topic name field.

Also discovered that statistics scans the log record trying to find a field that maps and returns a canonical userid. If for any reason the user misses, it shifts through all fields, and runs out of fields to log. So removing a user will cause statistics to mis-process the log records.

---

Crawford, can you look over this part of the Statistics process? Everything I've seen in the loggers assumes that the files are in a fixed field layout, I don't understand why the record is scanned trying to find a Canonical ID. I'd rather address the log parsing in the Logger eachEventSince routine and ensure that a username is returned if available, maybe return the UnknownUser if it isn't?

Do you have a corpus of old log records that eachEventSince needs to reliably scan? This would be really helpful.

-        while ( !$logFileUserName && scalar(@$line) ) {
-            $logFileUserName = shift @$line;
 
-            # Use Func::getCanonicalUserID because it accepts login,
-            # wikiname or web.wikiname
-            $logFileUserName =
-              Foswiki::Func::getCanonicalUserID($logFileUserName);
-        }

+        $logFileUserName = shift @$line;
+        # Use Func::getCanonicalUserID because it accepts login,
+        # wikiname or web.wikiname
+        my $canonicalUID = Foswiki::Func::getCanonicalUserID($logFileUserName);
+        $logFileUserName = $canonicalUID if ($canonicalUID);

---

I looked through the history of this code (a long way back) and think the scan happens because a very old version of the logger code generated records that had one or more blank fields at the start of some records, and the scan helped to make the code more robust to this circumstance.

My reaction is "bugger old log records" - a failing log file needs to be (manually) rotated out, simple as that.

-- CrawfordCurrie - 15 Mar 2013