That's not a fix, so much as a helpful workaround.

closed as duplicate of or subsumed within T214984

@Aklapper thanks - I've moved the contents to that ticket & will close this.

Let me add content from << T217103: Extension:Kartographer producing "Couldn't parse JSON" errors when SPARQL includes queryhints >> since this seems a part of the issue raised here and may provide an additional failure-mode example:

No, I'll not be doing that, any more than you just have. Whilst a serious outage is being treated merely as a curiosity, it is well worth reminding WMF employees that outages like this are far from acceptable.

Day 2 of no Quickstatements, no Listeria, no ETA for a resumption of service ... no comment from WMF on why what is a critical service - if we're taking this whole wikidata business at all seriously - is fritzed.

And to prove the curate's egg, http://petscan.wmflabs.org/?psid=7075446&al_commands=P31%3AQ5%0AP21%3AQ6581072 when run again, 502d.

Mixed results. The following three worked like a charm:

Sorry to burden you with this. As a user 502s are v.frustrating, but I can also imagine it's v.frustrating for you to be asked to debug when you could be making snowmen instead.

502 examples in the last couple of minutes:

Thanks Magnus. I run those two daily; get perhaps 20% 502s, without an obvious pattern. There are others (e.g. listed on https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Women_in_Red/Metrics/Wikidata ) which more reliably 502

How about we work out what's going on BEFORE we peremptorally close this issue. "As far as I know" does not cut it.

Ideally Cloud-Services will liaise with @Magnus either to bottom out & solve the issue; or else to provide an explanation for the 502 issue which we can use to console ourselves each time it happens.

So far as I know, the fault is not with Petscan, but with the WMF infrastructure on which it operates. Please do not be so hasty to dismiss problems like this.

@Jdlrobson Do we need to provide a description? Would not <meta name="twitter:card" content="title"/> provide our extant <title></title> contents to the twitter card. (I really don't know, but from first principles that seems to be what specifying content="title" would be likely to do.)

Is it really blocked, or is the best driving out the good? Would not something as simple as <meta name="twitter:card" content="title"/> be a massive improvement on the current highly suboptimal rendering - example: https://twitter.com/Tagishsimon/status/1064868689995071488

thx

Thx @LucasWerkmeister. All makes sense now :)

My regex is not great, but \?(\S*?)[\s\)}\.]

@Jonas - is there not a pattern that we could use instead of /^[\w\d]*/ ... we have a questionmark followed by not white space followed by a space or by ) or } or .

This issue is still occurring, lest anyone think we're done. I just got it on https://www.wikidata.org/wiki/Q55471970 when logged in.

see also T193214 which has a similar URL encoding issue.

You probably want to specify the issue here, Salgo60, rather than hope that the URL you provided will work in, say, 2 weeks time. (Hint: it won't.) The post in question says:

I think it might fall into the category of "being able to search for a formula without knowledge of the arcane ways in which it was mangled downstream of data entry".