Experienced the same error today again, here is an exact timestamp (of the response): Wed, 03 Aug 2022 17:15:19 GMT.

In T306899#7945324, @RKemper wrote:

@Dominicbm We made the error message is understandable by users part of the acceptance criteria of this ticket, so I think that's why T306919 was closed as a duplicate. Basically this ticket covers both the fixing of the actual problem as well as seeing what can be done to make the error message itself more comprehensible.

In T306899#8029731, @Gehel wrote:

@Dominicbm, @Fuzheado: did you see this issue again? Do you have a timestamp that we could correlate with the logs?

Closing, as this became the Pride event.

Update: This is now penciled in for July 28.

Using a particular variant is not an issue, so much as the lack of standardization. It causes a few issues, such as that they get treated as separate institutions in Indiana Memory and DPLA, which makes faceting on institution unreliable. It also complicates analytics in the DPLA dashboard, since these all appear separately. I suppose my suggestion of "IUPUI University Library" is not the canonical version in LCCN, so it's fine to use the other, though my inclination is always for the more human-readable name.

In T309351#7968210, @Lydia_Pintscher wrote:

Can you please clarify a bit more what the use case is? What would you like to achieve and when and why?

In T308696#7951916, @Aklapper wrote:

Hi, requested public project Indiana-Wikimedians has been created: https://phabricator.wikimedia.org/project/view/5949/

@Aklapper I don't know if I put this request in the right place, but just wanted to ping you in case.

In T258803#7948518, @AlexisJazz wrote:

In T258803#7939426, @Dominicbm wrote:

I get this error reliably when I search for "cors" as well.

What an odd coincidence, we searched for the same thing. (T308946) Were you also looking for a CORS related task to find a suitable tag? I ended up using a web search engine. There doesn't seem to be any tag for it, guess you're supposed to use "traffic" or something.

Funny, yeah I was filing T307391 and checking if the request was already documented.

In T306899#7942622, @RKemper wrote:

@Dominicbm @Fuzheado Understood that you all are still seeing these failures. We're still having trouble reproducing it on our end (we don't have great intuition as why but it's possible that the issue might only surface based on the geoDNS routing). We've added some further logging; next time any of you run into this issue if you could drop by the #wikimedia-search IRC channel and let us know, we can take a look at the logs and see if we can glean anything. Meanwhile on our end we'll keep trying to hone in on the source of the failure.

I get this error reliably when I search for "cors" as well.

@TheDJ Thanks for the info. That is helpful just to know this shouldn't persist beyond 3 weeks after a fix!

Honestly, if you are seeing few errors, it may also be that heavy users (like myself) are putting off our projects until the tool is more usable. If another data point is useful, I was using WCQS again today, and only submitted a couple of simple queries before I got another internal server error tonight.

In T301048#7922994, @Etonkovidova wrote:

The issue seems to be fixed in commons beta. The fix is scheduled to be deployed wmf.11 (wmf.12) next week.

Is this "fixed" in the sense that it will no longer occur, or is there a way to also make sure all files being affected at the time of deployment are also fixed?

In T307977#7917301, @Sebastian_Berlin-WMSE wrote:

I had a look in the logs and this seems to be caused by users not being created (T304090).

As a workaround try logging in on the home page at least once. This should create a user and logging in later should work.

@Gehel My intention was to have one ticket for the reliability issues, and one for the message itself, if that makes sense. Just wanted to point out, because the other one was merged into this, but the new AC for this ticket, which was supposed to be about the error and not the message, looks like it would be closed once the error message was improved but the error continued to occur.

In T224214#7911951, @Pintoch wrote:

However, wouldn't it be even simpler for the user to not even need the page id, and be able to add claims with a Commons file name?

I cannot speak for the team who designed the SDC features, but working with filenames is not always ideal. First, filenames can change over time (as files can be renamed), whereas pageids remain stable. Also, file names must be normalized, whereas Mids are simpler.

In T224214#7887358, @Pintoch wrote:

One helpful step in that direction would be to return the page id in the JSON response of a successful file upload. That should be fairly straightforward and would bring the number of requests required from three to two.

At the moment the process to upload a file with structured metadata is as follows:

• upload the file with action=upload
• retrieve the page id from the filename with action=query
• add the structured data with action=wbeditentity

If the page id was exposed, the second request would not be needed.

I created the subtask T307096 about this.

Also relevant to this task: most of the code samples provided in WCQS for a query (the button next to "download", "link") will not work without authentication, so this code needs to be updated or clarified in accompanying text.

I looked into this more and found a breadcrumb here: https://commons.wikimedia.org/wiki/Commons:SPARQL_query_service#API_endpoint

As an aside, the results in the example match the results given with a wbsearchentities request on Wikidata: