338:169 @ URL1 is

var cookies=document.cookie.split('; ')

Something's trying to access the cookie jar while the document is being destroyed?

Looks like a Firefox-specific error: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Dead_object

The JavaScript exception "can't access dead object" occurs when Firefox disallows add-ons to keep strong references to DOM objects after their parent document has been destroyed to improve in memory usage and to prevent memory leaks.

We're not in an add-on here, though...

I've bumped the alerting threshold for now to give us more time to fix since this doesn't seem to be impacting users.

I think it makes set to wrap mw.cookie.set( lastTickTime, now ); in a try/catch block for now.

I noticed for editing URLs, the users editing pages were rollbackers. Date.now().toString is not safe in this scenario, so PageTriage (T272904 ) could possibly be to blame, but that wouldn't explain the dead object message.

It's possible an ad blocker/or privacy tool is removing $.cookie, but I don't think there's much value in debugging this further.

Additional notes:

• There's nothing in the SAL from around the time that these errors started: https://wikitech.wikimedia.org/wiki/Server_Admin_Log#2021-05-11
• There's also nothing in the deployment calendar: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20210511T1100

In T282580#7080409, @Jdlrobson wrote:

I think it makes set to wrap mw.cookie.set( lastTickTime, now ); in a try/catch block for now.

I don't think we should modify production code to accomodate unsupported/unsupportable use cases. Especially not in a way that allows code to continue executing in unchartered waters. In an unknown codition like this, the specific module should not continue executing. Exceptions exist for this reason, and clearly the developers of Firefox also thought it made sense to throw in that case so as to halt further execution of related code. For example, do we know that try-catching this won't cause the surrounding code to make incorrect assumptions and continue in a way that may be create worse outcomes for the data end/or end-user experience? (not per se in a way that resutls in an exception)

If we want to ignore certain errors, ignore them, in Logstash. But let's not start a habit of try-catching everything just because a user sent some spam to our logs. The singularity this results in is a lot of wasted staff time, more brittle code that executes in ways we've never thought about or tested, inevitable confusion during refactors for why something exists, and of cource the circle of life in which these refactors do make the sensible decision to remove impossible conditions and then we start again.

It's possible an ad blocker/or privacy tool is removing $.cookie, but I don't think there's much value in debugging this further.

Per Sam's comment before this, the stack trace reports a line inside that method, with code that matches our source. I think that meant the method exists just fine and was not modified. It's thrown from the document.cookie accessor, not from accessing $.cookie (there is no throw statement in that method).

It affects Firefox on Linux, macOS and Windows, and seems diverse also across users, countries, and wikis; and happens at a rate that does not seem insignificant considering it is unsampled, and in relation to the expected pageview traffic from Firefox. Do we actually know that there isn't a problem? Even if it turns out to be caused by a browser extension, at this rate, it seems possible that it might be unintentional and that perhaps we need to reach out to the author's of such extension to understand what the intended behaviour/outcome should be.

I have a theory. I opened a tab yesterday, made sure I was bucketed and minimized it.

I just maximized that tab today and experienced some severe thrashing of resources. I watched it set > 1000 cookies in a short period of time (now it's at 8000 and counting). I suspect there's a point when for protection Firefox throws an error given the error relates to preventing memory leaks (I haven't got to that stage yet, but then my computer is probably more capable than most).

I should note it also made > 1000 beacon pings in a short space of time:

I think this script needs to be restricted to clear the interval it sets up at some point, rather than run indefinitely...

I've minimized the tab again. I will report back if I hit the error.

That aside, It doesn't explain why it started spiking suddenly.

Such unthrottled dispatching of cookies and beacons seems like a clear bug in the code and a performance problem indeed due to thrashing of CPU and network resources.

@MSantos Could this be prioritised in the current quarter?

Task appears to have fallen in a re-org gap and has not been migrated to a new workboard. Not sure if an isolated issue or not, and I don't know if event instrumentations moved to Product Infra or Product Analytics.