Software developer on the Wikidata team at Wikimedia Germany (he/him, Berlin timezone). Private account: @LucasWerkmeister.
Hm, on second thought, I’m not sure EditRequest / UrlInputEditRequest itself is the best place for all this parsing logic. Parsing the request requires some services (at least propertyDataTypeLookup, maybe also fullWikibaseItemInput and minimalItemInput), but if the parsing happens in a class that also gets the request as a constructor parameter, then we can’t add that class to the service container (since there we don’t have the request yet), and instead EditEndpoint will awkwardly have to pass the services to it.
There are also several ILoadBalancer methods with “master”:
Thanks. I’ll copy one comment here, since it seems more relevant for anyone else looking at this task (emphasis mine):
It’s not yet clear to me how error handling is supposed to work in the MediaWiki REST API. A REST handler itself (Handler subclass) is supposed to throw an HttpException, ideally a LocalizedHttpException, to return an HTTP error response, ideally with a localized error message. That’s what we currently do (at least insofar as we’ve converted die() calls to those exceptions, see T281804). But what are classes which are used by a REST handler supposed to do?
This is done now, as far as I can tell.
Wed, May 12
Come up with a plan of attack for the malformed values & get them out of the existing revisions set
Minor improvement: https://github.com/wmde/WikibaseReconcileEdit/pull/19
Tue, May 11
CI can be seen in action here: https://github.com/wmde/WikibaseReconcileEdit/actions/
Mon, May 10
Without this task, the second payload would have to look like this:
Example scenario: suppose the wiki has two properties, P1 and P2. P1 has type URL, and that URL is used for reconciliation, and P2 has type Item.
But I worry that replacing wdt:P279 with (p:P279/ps:P279) will also degrade performance significantly.
Not done yet IMHO (but waiting for T282243 for now).
Fri, May 7
The above log message notwithstanding, this still seems to be happening (and still with x-served-by: wdqs1012). I assume it’s not related to any particular query, but in case it is, I last saw it with https://w.wiki/3H$A (source).
First pull request, for EditEndpoint, is at https://github.com/wmde/WikibaseReconcileEdit/pull/11; I think injecting services into other classes (FullWikibaseItemInput/MinimalItemInput, SimplePutStrategy) needs to wait until those classes themselves have been moved to the service container (T282243).
Not done yet.
I don’t think that’s possible in SPARQL…
When I run the query, I get the header:
Should this appear on all installations of the query service UI, or only on query.wikidata.org? I feel like it should be specific to WDQS, but the current Gerrit change doesn’t make that configurable.
What if there are normal-rank and preferred-rank “subclass of” statements on the same item? The query service implementation would only use the preferred-rank statements – should the PHP version do the same?
Thu, May 6
Does this task also cover the MediaWiki REST API?
Wed, May 5
I’ll get started on this, but I think this can be done in several parts, given that the die() calls are currently a bit scattered across the codebase.
We’re targeting REL1_35, at least for now, so there’s no Wikibase services to use.
I can still reproduce it by visiting https://commons.m.wikimedia.org/wiki/File:%27%27Newspaper_Reader%27%27_by_J._Seward_Johnson_Jr._(1975).jpg. Note that the message are classified as warnings in the console, not errors, so you might need to tweak the console settings so they’re not hidden.
Tue, May 4
Probably requires us to know which MediaWiki/Wikibase version we’re targeting (1.36? master? 1.35?).