One more example https://en.wikipedia.org/wiki/File:Omaha_World-Hearld_Building.jpg

It was still working at 17:30, 17 October 2019 (https://en.wikipedia.org/wiki/File:Ajiyoshi_Station_in_Winter.jpg).

@Roy17 Yes, I noticed this too. The same thing happened with File:Anvil_Publish_logo.svg and other files. I remember it used to work well. Probably a Regression.

A few days ago it went back to normal, but now it's not functioning again.

It was functioning yesterday (22 Oct), but as of 17:18, 23 October 2019, it's not.

Some kind of seasonal bug???

It was not working at 09:16, 24 October 2019 https://en.wikipedia.org/wiki/File:Health_Research_Authority_logo.svg
but working again at 09:55, 24 October 2019 https://en.wikipedia.org/wiki/File:Horiba_company_logo.svg

Weird. Now it is working. https://en.wikipedia.org/w/index.php?title=File:Millers_Arms_Mathern_2.jpg&action=history https://en.wikipedia.org/w/index.php?title=File:Mike_Long,_Jim_McLaughlin_and_Graham_Shafer_(1618980902)_(cropped).jpg&action=history

It was working at 18:22, 30 October 2019.
Right now at 10:32, 1 November 2019‎, it's not working again.

In T235892#5626108, @Roy17 wrote:

It was working at 18:22, 30 October 2019.
Right now at 10:32, 1 November 2019‎, it's not working again.

It seems so. I was able to reproduce it today. See File:Downtownstatesborocourthouse.jpg on English Wikipedia. @thiemowmde how weird and unusual this bug can be! You guys really need to fix this ASAP.

And the same thing happened with https://en.wikipedia.org/wiki/File:Dowth2014_1.JPG . It didn't mark it with NowCommons. I can export some more files to Commons to test it if you want.

I'm gonna report on this bug for one last time.

It's working again 🤣 at 10:49, 2 November 2019‎ https://en.wikipedia.org/w/index.php?title=File:Train_from_Merthyr_Tydfill_at_Abercynon_Station_-_Snow_January_2013.jpg&action=history

Another user reporting the same issue: https://www.mediawiki.org/wiki/Topic:Vhm2enq0u01a86i0

Check log of errors that we log now.

Error messages to look for:

• "user can't use CentralAuth"
• "Remote API responded with an error"
• "failed to do post import edit"
• "failed to do post import delete"

I played around with https://logstash.wikimedia.org and found:

• 1 failed deletion: https://en.wikisource.org/wiki/File:Maulana_Muhammad_Ali_Quran.djvu. Except it did not failed: https://en.wikisource.org/wiki/File:Maulana_Muhammad_Ali_Quran.djvu?action=history. The log entry is dated 2020-05-02T14:54:12, the deletion done 2020-05-02T14:53:42, seconds before.
• 7 failed "post import edit" in the past 60 days. All within a few days, between 2020-06-06 and 2020-06-09.
• 3 of them have a meaningful referrer:
  • https://it.wikipedia.org/wiki/File:CappellaAdriano.jpg and https://it.wikipedia.org/wiki/File:CappellaSSSacramento.jpg, seconds apart, 2020-06-07T09:08:31 and 2020-06-07T09:08:34.
  • https://en.wikipedia.org/wiki/File:Angus_the_bulldog.jpg, 2020-06-09T02:17:02
• The other 4 are 2020-06-06T13:03:38, 2020-06-07T13:26:49, 2020-06-07T13:27:01, and 2020-06-07T13:27:30.
• Nothing suspicious about any of these source files.

Looking at the log messages surrounding these errors:

• The failed delete is because of failed to decode response from https://en.wikisource.org/w/api.php?centralauthtoken=…. Hard to tell. Unfortunately we don't log the full API request here, but I don't think this would tell us much.
• The error at 2020-06-09T02:17 is: Failed to get centralauthtoken: Failed to discover API location from: https://en.wikipedia.org/wiki/File:Angus_the_bulldog.jpg. HTTP status code 0. Error fetching URL: Failed to connect to url-downloader.eqiad.wikimedia.org port 8080: Connection refused. Looks like a temporary network error or something.
• All others are the same abusefilter-disallowed: This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: anti abuso bot.

My suggestions:

• Check if we show the expected yellow warning message about the failed remote edit in the AbuseFilter situation. (I believe we do.)
• We currently don't forward the AbuseFilter error message, and don't display it in the yellow warning box. It might be worth changing this.
• We should create a new sub-ticket of T223288: [Epic] Better handling of abuse filter + FileImporter interaction for this. Note this is not the same as T253872. The later is about filters on Commons, while this investigation here is about filters on the source wiki.

The investigation looks good and I agree with the next steps. I'd also suggest that someone try to adjust the anti abuso bot AbuseFilter rule to allow this specific edit. Moving to "Demo" to get product owner review.

Why is the option of automatically marking source file with nowcommons removed? Now every single file has to be tagged manually? Is that related to this?

@Roy17, this is a temporary bug, see T256428. We hope to get it fixed on Monday.