Yep, happy to review!
Yes, we're already looking up the Wikidata items in the LabelResolver class, so it should be relatively simple to update that class to gather the description and aliases as well.
It's somewhat of a broader issue, but IMO the presense of config.prod.yaml is confusing almost to the point of being misleading, since it's never actually used in production. I wouldn't be opposed to removing it.
The node/npm version combo packaged for Buster causes npm to throw this warning. Practically speaking, I have never seen an actual negative consequence of using them together.
Mon, Mar 30
Thanks for those estimates. I'll do some digging in the Echo tables and see what I can gather there as well.
Fri, Mar 27
For the latter option, I was using the term "job" loosely, and probably shouldn't have — I meant "job" in the general sense of "task," rather than a thing to put on the MW Job Queue. I was thinking more along the lines of a maintenance script that could run periodically on a cron job.
One final note: you may also want to follow T230845, which is a task to put a similar page media endpoint in the MediaWiki REST API as part of MediaWiki core.
Thu, Mar 26
A couple of follow-up questions:
Yes, @JoeWalsh is correct. The fatal problem with /page/media was that it was too heavyweight to serve without pre-generating and storing responses, and we lacked the dependency tracking mechanism needed to invalidate all relevant stored reponses in the event that a media item's metadata was changed. The cause of the performance issue is that it's very slow to parse extended unstructured metadata from File pages, compounded by the fact that the response often required such extended metadata for tens of files. (There is supposed to be some caching happening in MediaWiki to mitigate the performance problem, but I have a hard time believing it is working as intended, because the API response time does not improve over subsequent requests for extended metadata for the same files.)
Wed, Mar 25
Great! This is in the mediawiki/extensions/MachineVision repository.
Updated the description. @cooltey Does this make sense? Feel free to put a Hangout on my calendar if you'd like to discuss in greater detail.
Tue, Mar 24
As things stand today, I think the frontend will have to request and examine the existing claims before conditionally sending the wbsetclaim requests.
Yes, this can once again happen as a result of updating depicts setting to use the wbsetclaim API to resolve T241242.
What's the expected behavior?
Mon, Mar 23
Sat, Mar 21
Fri, Mar 20
When are you hoping for this to go live?
Thu, Mar 19
Actually, this appears nearly identical even without filtering for POST or api.php.
The Varnish web request 50x logs in Logstash (which I believe are sampled) are showing occasional 503s for various requests, not only wbsetlabel but also wbsetclaim (setting image captions) and echomarkread (marking notifications as read).
Wed, Mar 18
Updated the task title and description since: (1) there's an open question why this endpoint is showing internal traffic at all; and (2) this actually started at 15:00 UTC, which was before the mobileapps deployment around 23:00 that day.
- Do the estimated app user opt-in rates for push notifications that are given in the task description ring true to you?
- About how many push notifications would you like to see the average opted-in user receiving, in an ideal world? (Or is this entirely dependent on the user's level of on-wiki activity?)
As with the web implementation, tags are published using the wbsetclaim API provided directly by Wikibase, not a custom API. Ramsey said they haven't heard reports of such issues with the web feature when I asked just now. Possibly there's a bug in the app, though I personally haven't run into any trouble publishing tags while testing in the app.
Tue, Mar 17
This is long complete. Structured data is edited from CAT via the wbsetclaim API.