Task description:

at Date.prototype.toString URL1:170:660
at randomToken URL1:108:104
at initialize URL1:110:274

function randomToken() {
  return mw.user.generateRandomSessionId() + Date.now().toString( 36 );
}

There is no format variable here, and no method call to anything called replace(). Also, Date#toString is a native method, so from a stack trace perspective it seems impossible for it to be "inside" that method.

I would think that means the error is a "fake". That is, it isn't related to WikimediaEvents in any way, but rather something has messed with built-in prototypes and is just causing random code to fail. Could be a gadget or browser extension, hard to tell.

What is the rate? Any particular browsers?

I do agree it looks a little suspect. 170 errors every 12hrs across 10 IPs

I did wonder if someone was monkeypatching or replacing toString but couldn't find any evidence https://global-search.toolforge.org/?q=Date.prototype.toString+%5C%3D&regex=1&namespaces=&title=.*js

With additional debugging information hopefully some light will get shed.

I have found https://stackoverflow.com/questions/63255093/maps-googleapis-com-incompatible-with-date-js

Maybe someone is loading google maps from userjs and failing with it?

Change 670010 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/WikimediaEvents@master] Disable initDebugLogging

https://gerrit.wikimedia.org/r/670010

https://gerrit.wikimedia.org/g/mediawiki/extensions/WikimediaEvents/+/e74af1ec29085f726a07faa0b34bf453d4b00494/modules/ext.wikimediaEvents/searchSatisfaction.js#816

Not sure what's happening here, but it seems to impact a handful of users, and this error is allowing us to identify their browser viewing history (can provide usernames if it helps the investigation).

I'd recommend turning this off anyway, logging twice for an error now we have global error handling seems unnecessary.

Change 670010 merged by jenkins-bot:
[mediawiki/extensions/WikimediaEvents@master] Disable initDebugLogging

https://gerrit.wikimedia.org/r/670010

This error may have spiked back up according to the latest graphs:

https://logstash.wikimedia.org/goto/6a45e81278db0ee7a31c6e2eeeef0d3d

For me it is https://test.wikipedia.org/wiki/Special:NewPagesFeed where the resource loader module with that script is loaded.

Date.now() returns normally a number, and than the toString is called there

But the linked file has:

Date.now = function() {
    return new Date();
};
...
Date.prototype._toString = Date.prototype.toString;
Date.prototype.toString = function(format) {
    var self = this;
    var p = function p(s) {
        return (s.toString().length == 1) ? "0" + s : s;
    };
    return format ? format.replace(/dd?d?d?|MM?M?M?|yy?y?y?|hh?|HH?|mm?|ss?|tt?|zz?z?/g, function(format) {
        switch (format) {
....

And than Date#toString is called by the randomToken from above. toString is calling the replace function on the given format arg (which is the 36, expected as radix) and that fails.

It is a bad idea to change return types ...

Needs migration to another lib for localization of dates like moment or jquery.ui.datepicker or OOUI elements? Not sure where it is used on that page.

Change 683103 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/PageTriage@master] Drop modifications to Date.prototype

https://gerrit.wikimedia.org/r/683103

I would recommend PageTriage drops that code. The worse thing that can happen from what I can see is that some of the rendered dates will render differently. Looking at the unminified date.js I see a lot of monkey patching and defining of Date.prototype functions.

From what I can see, PageTriage uses this library only for the Date.parseExact function and modified Date.prototype.toString that library provides:

Date.getParseFunction = function (fx) {
    var fn = Date.Grammar.formats(fx);
    return function (s) {
        var r = null;
        try {
            r = fn.call({}, s);
        } catch (e) {
            return null;
        }
        return r[1].length === 0 ? r[0] : null;
    };
};

Date.parseExact = function (s, fx) {
    return Date.getParseFunction(fx)(s);
};

IF we don't feel comfortable deleting, we could unminify the code, and cut out the cruft without the modification of the global Date object.

Example usages:

    parsedTimestamp = Date.parseExact(
					historyItem.get( 'timestamp' ),
					'yyyy-MM-ddTHH:mm:ssZ'
				);

	historyItem.set(
					'timestamp_time',
					parsedTimestamp.toString( mw.msg( 'pagetriage-info-timestamp-time-format' ) )
				);
`

Change 683128 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/extensions/WikimediaEvents@master] Revert "Disable initDebugLogging"

https://gerrit.wikimedia.org/r/683128

Change 683103 abandoned by Jdlrobson:

[mediawiki/extensions/PageTriage@master] Drop modifications to Date.prototype

Reason:

See analysis on ticket. Likely need to find a replacement library or scope this to PageTriage. Can't just remove as the parsing functions this adds seem to be in use.

https://gerrit.wikimedia.org/r/683103

The last release of DateJs was 2007 and is the one we are shipping in case we were wondering if upgrading was an option :) https://github.com/datejs/Datejs

@Jdlrobson is this still considered an UBN?

It depends. I defer to your judgment (with input from search team who's instrumentation is being impacted by this bug).
This error appears to currently be restricted to en.wikipedia.org. Right now I see 131 events in a 12hr period. (Presumably that's because English Wikipedia is the only wiki which has both PageTriage and event logging for SearchSatisfaction setup.)

Per our train guidelines, we block the train when there are over 1000 errors in a 12 hr period for new issues. This is neither an existing issue or over 1000 errors so not UBN by that definition.

Really the priority here comes down to how your team wants to manage their risk and impact on other teams. Given this script is modifying a native browser function Date.prototype.toString, presumably if any new code makes use of Date.prototype.toString then this could hypothetically quite easily lead to a new error with a rate of higher than 1000 errors in a 12 hr period and this will be considered a train blocker. The less users that have page triage rights, the less the risk is here.

Feel free to adjust the priority as you see fit.

Potentially this is fixed by T268513: PageTriage's external Date.js modifies/overwrites native JavaScript Date prototype, should be updated

Change 730702 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/extensions/PageTriage@master] Replace deprecated date.js library with moment

https://gerrit.wikimedia.org/r/730702

Change 730702 merged by jenkins-bot:

[mediawiki/extensions/PageTriage@master] Replace deprecated date.js library with moment

https://gerrit.wikimedia.org/r/730702