Absolutely supporting the nomination!

@hoo: any update on this? Or should we return this to the Backlog for others to pick up?

AFAIK, the main reason it exists is to load all the labels for the properties to be displayed on a page in a single query. I've found code doing it for the client, but don't see this for the entity page (I remember it was there, but things have probably changed).

This should be fixed now (finally) on all client WMF wikis.
@Addshore has deleted the Abuse Filter rule, so use of lexemes in statements is now possible.

Well, I vaguely remember loading the php-serialization from cache being about 30% faster than deserializing JSON, but I can't quite remember where I benchmarked this (probably benchmarked this while working on dumps). When considering this, we should really benchmark this thoroughly.

Maybe IP-whitelisting is not needed, or reasonable solution here. In any case, WMDE is having issues using Phabricator today (July, 2nd 2018), and I guess this is due to some measures introduced after last weekend's vandalism.

@Lucas_Werkmeister_WMDE is amazing and created a script that finds tools that are somehow using wb_terms. The results are at P7299. The script, for reference, is P7298. Thanks Lucas!
We'll use this input as well. But of course more detailed and personal input like from folks above is always helpful!

@Pablo-WMDE and me tried a bit more to make some sense from the "Special:RecentChanges shows page creation" failure.
If we read MW code correctly, make an edit results in calling RecentChange::notifyEdit, which in turn saves the RC object as a "deferred update".
We guess this is why the problems might be coming from.

Regarding screen caps #1 and #2, it would be interesting to see if what is send to server is just "0.5" (i.e. save clicked too fast), or is the full long string input and sent (that would mean that server-side does some weird interpreting string as number stuff)?

#3 quibble-vendor-mysql-hhvm-docker/6069/shows-page-creation.png

Regarding #3 my working hypothesis is that either the change made in the test is not visible in RecentChanges (is it really possible? maybe edit simple fails?), or there is another edit coming kind of simultaneously that comes before the one made by the RC test. selenium test are not run in parallel or something?

Well, that patch only moved code around, so although could be that it is causing some issues, I cannot think of how it would happen :)

@Legoktm as I just randomly remembered this issue: any answer/progress so far?

Forms TBC

Use cases

Yup, something like this would rather be needed here. Will have a look after the weekend.

I am not a docker ninja, but when in a need to remove ALL docker stuff I use: docker system prune.
Note that it is going to remove all stopped containers, not only mediawiki ones (if you have others running).
Also keep in mind the note about volumes from the docs (i.e. if you want to remove all all then also run: docker system prune --volumes)

I don't want to stop a discussion or anything, just to avoid possible misunderstanding. I didn't mention SPARQL as the considered replacement for wb_terms for tools. I am pretty sure it wouldn't be a good alternative for most of the tools, so we are not even really considering this path :)

Just looking at the error message it would seem composer didn't pull in dependencies. But looking at README.md running composer is mentioned to be done before running update.php (which makes sense), so I don't quite get why it could fail.

@zeljkofilipin: looking forward to see what you come up with!

no such file to load -- /srv/jenkins-workspace/workspace/selenium-WikibaseLexeme-chrome/BROWSER/chrome/MEDIAWIKI_ENVIRONMENT/beta/PLATFORM/Linux/label/DebianJessie && contintLabsSlave/tests/browser/features/support/../../../../../Wikibase/tests/browser/features/support/modules (LoadError)

Thanks @Mahir256, @Magnus, @Nikki for comments, that's very helpful!

Thanks @hashar for the insight. I am trying to do something along the lines of what you've described. Expect patches soon :)

Based on queries against wb_terms replicas, numbers look the following, as of today:

• Number of labels: 250 M (250 778 841)
• Average length of a label: 22.8056

What line in Wikibase actually does this unserialization? perhaps we could change that to something that wouldn't have such a global effect.

oh I messed up pings.
E.g. I wanted to ping @aaron not Ariel. Sorry folks!

https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/437495/ fixes the problem but when cache is used there is a PHP serialization issue resulting with fatals: T197252.

Some options to overcome the issue (list not complete and not sorted in any way)