[15:31:39] ori interesting. so, it requires GC to kick in. in the general case, you cannot guarantee that all live refs to the node being deleted have been unset before the next call to getElementById [19:52:16] Reedy: any chances you could schedule some time to clear the new backlog of server side uploads? [19:52:37] or anyone with prod access fwiw [19:57:26] How many are there? [19:57:39] Like 6/7 iirc [19:57:48] not much [19:58:56] https://phabricator.wikimedia.org/project/view/2141/ and https://phabricator.wikimedia.org/T216118 [19:59:12] so 4 [21:36:26] hauskatze: Only one is actionable [21:36:38] oh [21:36:46] files expired on the rest of them? [21:36:52] Two already exist [21:36:59] One missing a description [21:37:56] One is sitting stalled since the last time I did any [21:38:31] Thanks for taking a look nonetheless. [21:38:45] Pause for dinner. [21:39:04] I'm doing the one that is ok [21:39:58] We should ask the others to fix the request with what's missing IMHO. [22:17:01] Reedy: Is https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/443866/ still something you want to do? [22:17:34] It's arbitary, but should effectively be a noop [22:17:48] Can probably do 2017 or 2018 at this point [22:18:10] well, defintely 2017 [22:21:00] Reedy: What is the intended impact, though? Parser cache is TTL-based, as is the CDN/Varnish max-age headers. And ResourceLoader was updated to do to the weird thing it was doing. [22:21:11] I think we should consider deprecate it instead. [22:21:28] I wonder what still uses it, and whether that should be changed instead. I can't think of anything that *should* use it. [22:21:50] Wikidata unfortunately has had to use it... [22:21:50] Hence it being 4 years newer [22:21:53] But it's 18 months since they last did too [22:23:12] There's potentially older thumbnails (in Swift) that wouldn't be harmed by regeneratd I'm sure :P [22:23:31] Hm.. how does that work? [22:24:33] // Check if an up-to-date thumbnail already exists... [22:24:33] wfDebug( __METHOD__ . ": Doing stat for $thumbPath\n" ); [22:24:33] if ( !( $flags & self::RENDER_FORCE ) && $this->repo->fileExists( $thumbPath ) ) { [22:24:33] $timestamp = $this->repo->getFileTimestamp( $thumbPath ); [22:24:33] if ( $timestamp !== false && $timestamp >= $wgThumbnailEpoch ) { [22:31:34] Reedy: Right, but afaik that codepath is bypassed in prod. On page views while parsing the earlier branch will have returned already via 404 handler. And for other scenarios (upload, and pre-render jobs), expiry isn't an issue. The third scenario is thumb requests themselves, which are typically routed directly from the file system (third party wikis) or Swift proxy (WMF), so this code wouldn't run at that point. [22:31:51] Even accessing thumb.php and on private wikis, MW debounces and routes to Thumbor directly. [22:32:12] I won't say it's impossible to hit somehow, but it's not a primary mechanism that is actively doing something in general. [22:32:59] The main way this code path is hit is for third party wikis that also don't use 404 handling, then, while parsing wikitext, MW will evaluate whether the on-disk thumb is recent enough to re-use. [22:34:03] Which I'm not sure why that exists, given there's no special handling to account for stampedes, so might as well remove this variable in favour of documenting that if you want to cache miss everything at once, simply use rm -rf instead. [22:34:18] (anyway, i was referring to the other Epoch variable, didn't realise your commit changed both) [22:35:39] Feel free to abandon the commit if it's offending you [22:35:58] I'm hardly attached to it :) [22:36:07] [22:20:30] I think we should consider deprecate it instead. [22:36:14] Like a lot of things, IS is full of crap [22:36:30] Hehe, updating wgThumbnailEpoch seems fine. [22:36:52] I'm worried about the other one though, because I still have this impression that its a nuclear thing that is used in tons of things. [22:37:14] I can't imagine we have much around from a few years ago though [22:37:38] Well, until recently, it was also used in cache keys for ResourceLoader. Which means instant global cache miss. [22:37:52] I've since removed it from RL in December I think. [22:38:05] Yeah, it's no longer used there. [22:38:33] I don't know if anything else uses it that way. [22:38:42] If not, lowering/raising it seems fine, yeah. [22:38:55] I'm not worried about not having cache from 2 years ago. [22:39:05] Given it's quite likely we don't have any anyway. [22:44:27] The one you just rebased... That one is more useful :P [22:51:50] :)