Moving to Review column, because the first two patches are ready for review, I think. The third part will have to wait for the wdio-wikibase package to be extracted (T200011).

Waiting for train deployment. Then we can go ahead with the next config change either on Thursday or next week.

Thanks!

Yes, if we track the number of entities, we should be able to get different percentiles in Grafana. I’ll upload a patch for this, hopefully we can get it merged in time for this week’s train.

Apparently, the string length validator now looks like this in production:

Hm, perhaps it would be good to have some tracking on the number of entities processed in PHP before we increase the limit further. What do you think?

Hm, I don’t think that’s something we need to deal with at the Wikibase level… I feel like this is something that’s best dealt with at the HTTP proxy level. Apart from the other repo’s IP address (that the request is coming from), the current instance doesn’t necessarily know anything about the other repo anyways, does it?

Lydia says we can just change the brand to include the word “service” – see the above change.

Yes, but it’s a similar class of potential error, if I understand correctly, just not as critical.

I don’t understand this part:

@Tchanders FYI, in another change we noticed that we’d also failed to override requiresWrite – could that require a similar investigation?

Note: as currently implemented, this will change the title on query.wikidata.org from “Wikidata Query Service” to “Wikidata Query”, without the “Service” (because that’s the name that’s displayed in the upper left corner, between the logo and the “examples” button). We may need to split the “brand” into two different strings to preserve the current WDQS behavior.

Note: users can block and unblock themselves (I just tested it on my local wiki), so we should be able to test this using the regular test account, assuming that’s an admin. (To be safe, make the block expire soon, so that we don’t leave an indefinitely blocked user behind if a test fails.)

Um, actually, way longer strings are apparently still permitted…?

I believe it’s 1500 characters (example edit), for monolingual text, strings, and URLs.

Thanks! I’ll let you know if I notice it in other channels, but I’m not currently aware of any.

@Pintoch thanks for reminding me that I still needed to send the announcement ;) closing now.

But that’ll require us to rework the whole deployment process of the WDQS UI, and place extra requirements on third-party installs as well (a static site can be served from any service provider). We already have a build step before deployment – we could also apply the necessary adjustments there.

I think so, yes.

For the record: in Special:EntityData, this has been available since I247191817f (early 2013) via the oldid or revision URL query parameter (example). It’s only missing in the API (wbgetentities).

In T210901#4794821, @Addshore wrote:

We currently don't enable access to old revisions via any API T40971

The HD logo for itwikisource, deployed to the debug server earlier today as part of this change, looked broken (screenshot at 150% zoom):

FWIW, I can tell you that CheckConstraintsRdf in WikibaseQualityConstraints is safe (it’s a read-only action), and I’m confident it has no subclasses (it would not make sense for any other extension to subclass it).

@Addshore’s patch is already merged (on master – the wmf.6 backport is abandoned).

No more errors in Logstash since the 29th, when Wikidata went back on wmf.6 (after some unrelated issues). Checking constraints on Q2518823 works now (and the item still features a value for a deleted item). Looks fixed to me.

I don’t think we’ll be able to see this in Grafana (Network traffic panel), query traffic from WBQC is probably not significant next to other query traffic and updater traffic. Closing.

As far as I can tell, all the changes relevant to this task are merged now (there are still some open for the subtask T205252). Moving to the verification column – hopefully we should see the Grafana stats improve once this goes out with the train.

Forgot to unstall this – should be deployed now, I’ll check Grafana in a few hours to see if I can see any trace of this change at all, but otherwise it should hopefully Just Work™.

But /prop/direct/P279 gives no RDF, just HTML

I think we can close this task – the tool exists (https://tools.wmflabs.org/wdmm/), and all the features from the task description are available, except for directly sending the MassMessage (optional).

Why should we do this in the proxy? Much easier to do it in the web UI IMHO.

For RDF users , this is really blocking.

Link to one of the failing jobs, for convenience:

I don’t think so, why? The already merged patches are mostly for displaying coordinates on the repo, whereas the linked chain is for the client, if I understand correctly.

The change adding the test was reverted in Id2eeeb781b (I’m not sure why @gerritbot didn’t leave a comment), and since then I haven’t seen any more occurrences of this bug, so the CI issue seems to be resolved.

• The end of the chain is https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/461697/, but the rest of the chain needs to be merged and on the way to deployment before we merge this one.

Config change is reviewed and will be deployed with Monday’s EU SWAT, so moving out of the review column for now.

WikibaseCodeSniffer now has a 0.5.1 release to pull in MediaWiki CodeSniffer 19.1.0 (thanks for the issue @Umherirrender!), so let’s reopen this task to track all the repositories that now need to pull in 0.5.1 instead of 0.5.0.

(Minor note to avoid potential confusion: I also have non-work accounts, “LucasWerkmeister” on Phabricator and “Lucas Werkmeister <mail@lucaswerkmeister.de>” on Gerrit – those should not get any special rights, since I only rarely use them.)

I feel like two things are being conflated here… there are two changes made by the automatic formatting: the variable and values are parenthesized, and the list is split across multiple lines. The title and the beginning of the task description only talk about the parentheses, but then the rationale only explains why the multi-line change is bad…

No, but I think the data value is supposed to be useful on its own as well, that’s why it has its own type information.

The only thing we have right now is the number of checks that stayed within the threshold vs. the number of checks that exceeded it. Do you think we should add additional tracking before deploying the config change?

See also T203320: Ctrl/Control-Space is overridden by keyboard layout changing shortcut on macOS. (I’m not sure if the two tasks should be merged or kept separate, but they’re definitely related.)