@fnegri in principle yes, but it shouldn't be that bad, plus it's only occasionally; right now, there is not a single query running. If you can get SQL from such a query, I can investigate.

I have fixed some queries using the wrong FORCE INDEX, that should help. I am backfilling some backlog tasks, the current load is not indicitative of long-term behaviour.

I have deployed some fixes, let me know if it makes a difference

Added now

See https://commons.wikimedia.org/wiki/Help_talk:FastCCI#Rust_back-end for an alternative

Sure

In T431121#12094420, @1Veertje wrote:

@Magnus would you be ok with giving Translatewiki push permission to the Flickr2Commons repo?
Project maintainers have to decide if they want a direct push or pull requests.

Seems to work again

Yes, seems to work, thanks!

The anon_1 thing is not mine, AFAICT

OK, s51434__mixnmatch_p and s52421__commonsdelinquent_p are mine.

Update: I rewrote parts of wikidata-terminator to be able to skip the giant update-happy table entirely. the table is already deleted, albeit there is a new, smaller one. [Starship Toopers meme] I'm doing my part!

No joy. I will deactivate the wikidata-terminator update script for now until I understand what's wrong.

As for wikidata-terminator, looks like it was trying to update from recent changes - since 2023...

My tools:

• s51205__terminator_p cause TBD
• s55078__wdrc_p has a lot of updates by its nature, but it should clean up after itself, that is, the table(s) will not grow infinitely
• s51434__mixnmatch_p should have lower usage except imports, but right now I'm running a cache warmer that should finish in a few days, keep an eye

Trying to fix update flood: https://codeberg.org/magnusmanske/wikidata-terminator/commit/18ce520293ad93078d38c8b63ba8268021a24483

Last commit was 5 years ago https://codeberg.org/magnusmanske/wikidata-terminator/commits/branch/master

No recent change I remember.

I'll have a look at wikidata-terminator

That worked, many thanks!

I also fixed the version on enwp but I'm not an admin there anymore, so I can't change it, someone please try: https://en.wikipedia.org/wiki/User:Magnus_Manske/Wdsearch-autodesc.js

I think I fixed it for http://tools.wmflabs.org/wikidata-todo/autodesc.js

Update: Now it says "running" on toolforge jobs list. I didn't change anything. Might just have been a fluke.

Only one I saw. build failed earlier today with "empty image" but I think that was something else. Didn't repeat.

This implements a toolforge-side proxy, that should help.

Update: Seems to work now, waiting for completion (it's been slow the last few days)

thanks!

If I change the manual https:// to http:// it works. These things should be clarified in the manual IMHO. Otherwise, this can be closed, works-for-me.

Ah, I understand this only works from within other jobs, not from the normal shell, which is a pity. Anyhow, I tried from a sehll webservice, and it still won't work, albeit with a different error:

tools.mix-n-match@shell-1776351170:~$ curl -v  'https://rustbot:8089/api?action=run_lua&function=PERSON_DATE&entry_id=205975229'
* Host rustbot:8089 was resolved.
* IPv6: (none)
* IPv4: 10.97.159.239
*   Trying 10.97.159.239:8089...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* Send failure: Broken pipe
* TLSv1.3 (OUT), TLS alert, record overflow (534):
* TLS connect error: error:0A0000C6:SSL routines::packet length too long
* closing connection #0
curl: (35) Send failure: Broken pipe

FWIW I have now moved all my "active" tools from bitbucket to codeberg. Some archived old tools remain on bitbucket, for now

V2 should be fixed now

Oops, I'll fix it in V2

I have added the project.toml file to both my repo root and the tool root. Same thing.

I have implemented the idea of @Mahir256 in both PHP and Rust, and put everything live. Please test. Note that I might not be able to reply until tomorrow.

@Mahir256 Nice idea, let me try this

@VIGNERON The LAST after ADD_FORM referred to the FORM not to the Lexeme. This is indeed confusing, so I changed it to use LAST to refer to the last Lexeme created. Please try again (with a new Lexeme), it should work now. I also changed the docs accordingly.

I have added the required Lexeme fixes to both the PHP and the (back-end) Rust version. Specifics are here (not yet in the official help page). Can someone more familiar with Lexemes give it a whirl please, before I announce it to the general population?

IIRC full Lexeme support was postponed so we can start Lexemes on Wikidata "clean", and not as a mass import from Wiktionary or some copyright-dubious source. If we agree that Lexemes have reached critical mass, I can add Lexeme support to QuickStatements, unless you want to wait for that rewrite (who was doing this? Brasil?)