Null edit triggers update, but looks like a purge also does that. At least that is a less intensive operation. As a workaround we can just mass purge suspected files.

Multichill, I think this might be duplicate of T237991. As someone who works with commons categories based on SDC and Wikidata I always seem to have bot running null-edit batch tasks. I use AWB for that. Those edits do not show up in the page or bot edits, but I do a lot of it.

Another category that needs constant refreshing is c:Category:Pages_with_script_errors. There are often files there but they all disappear after nul edit.

In T245349#5888188, @Jarekt wrote:

Multichill, I think this might be duplicate of T237991.

I think you're right, but that bug hasn't even been touched by the SDC team. @Ramsey-WMF @Keegan who is supposed to manage these boards? It's a bit pointless of us filing bugs for the SDC team if nobody is noticing it.

I've added tags for the main boards the SDC team monitors. We do monitor as many relevant boards as possible, but incoming SDC work across WMDE and WMF focuses mainly on these at the moment.

Our team is small and, as you're aware, we're working on other important tasks at the moment. But we will get to this one as soon as we can. Thank you for your patience.

I just run into this issue again. c:Category:Files with PermissionOTRS template but without P6305 SDC statement is added to files fith OTRS template but without P6305 statement and it has 47k files . I just added P6305 to 20k of them, and there is stil 47k files in the category. I would like for them to disappear from the category so I can use it to find more candidates.

I just run into this issue again. c:Category:Files with PermissionOTRS template but without P6305 SDC statement is added to files fith OTRS template but without P6305 statement and it had 47k files on 4/14 . I added P6305 to 20k of them, and afterwards there were still 47k files in the category. I would like for them to disappear from the category so I can use it to find the next 20k batch. Otherwise I might have to apply "touch" operation on the folder, which now have 70k files.

Change 602053 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/core@master] Remove unwanted parse step

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

Change 602053 merged by jenkins-bot:
[mediawiki/core@master] Remove unwanted parse step

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

This (finally - thanks @Tgr!) got merged.
@Jarekt or @Multichill, any chance either of you could verify that this got fixed? (happy to wait if it's too much hassle to try to reproduce!)

In T245349#6550112, @matthiasmullie wrote:

This (finally - thanks @Tgr!) got merged.
@Jarekt or @Multichill, any chance either of you could verify that this got fixed? (happy to wait if it's too much hassle to try to reproduce!)

The easy cases shouldn't be hard to verify. Is this change live on Commons now?

Yes, that has already been deployed to Commons, so I'm hoping that this issue is now gone :)

Not sure if this is related: https://commons.wikimedia.org/wiki/Category:Creative_Commons_Attribution-Share_Alike_4.0_International_missing_SDC_copyright_license is empty now, but https://commons.wikimedia.org/w/index.php?sort=last_edit_desc&search=incategory%3ACreative_Commons_Attribution-Share_Alike_4.0_International_missing_SDC_copyright_license&title=Special%3ASearch&profile=advanced&fulltext=1&advancedSearch-current=%7B%7D&ns0=1&ns6=1&ns9=1&ns12=1&ns14=1&ns100=1&ns106=1 returns over 400.000 hits.

Update: Sorted by date. Seems a big glitch on 18th. My bots do a null edit so no clear why that wasn't picked up

It's not just an Oct. 18th thing - the incategory search shows files before that date as well, at a pretty consistent daily rate.
I can't figure out why it suddenly stopped on Oct. 18, though - did the relevant bot stop running?
It looks like this is not a regression, as it appears to have already been happening weeks ago (before this patch was even deployed)

Curious observation: when I do a null edit on those files now, the category disappears from the page & the elastic index, and it's gone from the search results. I have no idea why the bot's null edit didn't seem to have had that same effect.
Regardless - a null edit shouldn't be required, and I bet it's a similar issue that caused categories to not be updated. Looking into it.

Presumably the bot doesn't do an actual null edit but calls the purge API? Those things are supposed to do the same but the actual code path is fairly different.

In T245349#6572376, @Tgr wrote:

Presumably the bot doesn't do an actual null edit but calls the purge API? Those things are supposed to do the same but the actual code path is fairly different.

Nope, it's a real edit. It does even show up in the edit history every once in a while (some one byte glitch).

I am able to reproduce in production, but things now work fine on a similar local setup.
However, if I call $mainContent->getParserOutput() in a PageContentSave (deprecated) hook, I manage to get a similar behavior.

ATM, I suspect that an extension will hook into the page save process and cause a premature parse, which ends up getting cached (causing similar behaviour that the earlier patch addressed)
Still trying to figure out exactly how & where that happens, and what would solve it...

(also, clueless about why the null edit has no effect, but a manual purge/null edit later on does)