The fix for this is merged, and should roll out before the next script run.
Deployed on eqiad and codfw. Thank you, @akosiaris!
Wed, Nov 20
Hmm, that is surprising. My workaround suggestion was based on https://github.com/wikimedia/change-propagation/pull/223 but maybe something has changed since then. @Pchelolo probably knows more.
Looks like there are currently issues accessing docker-registry.wikimedia.org, which may be to blame here.
As a workaround, I believe that performing a purge or null edit of the article will trigger a PCS update that will pull in changes to transcluded content.
@JoeWalsh This doesn't appear to have occurred since that change was deployed. I'll update if/when a newer trace is available.
Please reopen if repro steps are found.
If I understand correctly, the issue here is that the Page Content Service content was updated in response to edits to the Wikipedia page content ( https://de.wikipedia.org/wiki/Briar_(Instant_Messenger) ), but not in response to edits to the corresponding Wikidata item (https://www.wikidata.org/wiki/Q18210428) from which properties are pulled in via https://de.wikipedia.org/wiki/Vorlage:Infobox_Software.
Ah, I see the issue now. T237859 is a distinct issue, and I'll follow up there with further dicussion. In the meantime, I'm going to be bold and close this task. New incidents should be documented in new tasks.
This issue concerns the service(s) that propagate resource change events and issue update requests resulting from such changes to the Page Content Service. Those are maintained by the Core Platform Team, so I'm tagging them here.
Tue, Nov 19
One thing I think is worth making explicit on this ticket is whether this endpoint is intended to return only media items that are part of the article content, or all linked media items. For example, on enwiki, many articles with linked media content contain an imagelink to Commons-logo.svg via the inclusion of Template:Commons_category. Is the intent to include images like these in the response, or to try and restrict inclusion to images more likely to be interesting to the caller? The media/media-list endpoints in mobileapps attempt to do the latter, but I'm not sure whether you intend to go down that road again here.
Mon, Nov 18
This was implemented as a MediaWiki extension, and there is no plan to add an external service component.
De-prioritizing and moving to the PI backlog until this can be reproduced.
Fri, Nov 15
Upon further reflection, a new column isn't required for this. Reverts can be identified by tag and the confidence score for the associated label up in machine_vision_suggestion.
Thanks, @jcrespo. It looks like the only practical effect in this case is the logspam, so I'll let the script run its course this time. Thanks also for the recommendations — that makes sense. We'll update accordingly for the next run.
Ah, I just scrolled up and found https://meta.wikimedia.org/wiki/Schema:MachineAidedDepictsUsage (again) -- @Ramsey-WMF, thoughts?
Hi @Ramsey-WMF & @mpopov, I drafted an EventLogging schema for Special:SuggestedTags interactions: https://meta.wikimedia.org/wiki/Schema:SuggestedTagsAction. Please let me know your thoughts when you get a chance.
Thu, Nov 14
The problem is this line, calling commitTransaction when no transaction has been opened: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MachineVision/+/master/maintenance/fetchSuggestions.php#81
Just to add a (negative) data point, I have never seen this.
Wed, Nov 13
This is the stack trace I'm seeing in exception.log log mwlog1001 that almost certainly corresponds to this bug.
This is consistent with my testing as well. In FF, the page returns to its exact previous state, and in Chromium, the API is re-queried. In neither case do I see images for which I've already voted.
I cannot reproduce this, so I'll give it up to others to try. For the record, I tried locally, on test-commons, and on production Commons with Chromium 78.0.3904.70 and Firefox 70.0.1 on Ubuntu 18.04.