This issue is still occurring. We still get different answers depending on which report server we hit. That is clearly suboptimal. Could we please have an update on action being taken, and/or the timetable for proposed action, presuming that action will be taken. @Lydia_Pintscher

It may or may be not useful to note that Quickstatements, when used in (server-side) batch mode to create new items, creates duplicates at the rate of about 10% of the items created. QS run locally from a browser does not exhibit the problem.

Magnus was running 2 quickstatement batches at the time he got the above. My experience of this issue is that it'll sometimes happen when I have a QS or two running, but has never happened absent a QS.

UI which has the capacity to mangle input and demands that the user must do something beyond their simple input of the date, is unambiguously, categorically and unimpeachably broken. It should be considered as such.

We could maybe have a preference, such that the user can specify whether they want date parsing to be based on an assumption of MM/DD/YYYY or DD/MM/YYYY. Stop guessing. Ask the users.

Is there a problem with increasing the size limit. It /seems/ like a very easy quickwin. What's the story?

Wikidata currently gets ~660k edits per day.

Notable that WDQS lag seems to be paying not a blind bit of notice to this change :(

Per Laske, SPARQL for this issue in Germany [https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Surplus_of_coordinates_-_T198078]

Ditto http://www.wikidata.org/entity/Q17567523 ... there are probably others.

@Smalyshev Please check out the single coords property at https://www.wikidata.org/wiki/Q6522893#P625 versus the two rows returned by this query, suggestive of 'hidden' triples lurking still.

And note Ethan's assertion: The scheme for Geonames URIs requires a trailing forward slash.

Fix by all means, but I note "It is an error for aggregates to project variables with a name already used in other aggregate projections, or in the WHERE clause." https://www.w3.org/TR/sparql11-query/#aggregateExample

Tested - works for me in situation in which it previously didn't work.

Can I gently detach this issue, somewhat, from disputed territory. The current situation is that maps served by Wikipedias & (my key use) Wikidata WDQS use "OSM Bright for Mapbox Studio" tiles ( https://foundation.wikimedia.org/wiki/Maps_Terms_of_Use#Where_does_the_map_data_come_from? )

Worth noting that user:Twofivesixbot

@FriedhelmW ... purge != clear cache. https://www.refreshyourcache.com/en/home/

Seems more likely it's a data input issue than a query issue @matej_suchanek, given that WDQS doesn't exhibit the same sort of error for analogous wdtn:, such as wdtn:P244 (Library of Congress authority ID) - see for instance https://w.wiki/48X

de link is showing. local caching issue for @FriedhelmW ?

+1 for this. Further example of a long SPARQL report is at https://twitter.com/Tagishsimon/status/1128769104674996234 fwiw

And the clear risk with this issue is that if one enters a search term that should get a match ... for instance - Judith Schwarz - and places a reliance on the dropdown, then seeing no dropdown, as if the search term did not match anything, will, for instance, lead to the creation of duplicates.

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".