What is the status on this? The lack of IPv6 support of the webservice seems to be one of the reasons for slow connections from some internet providers. T362822

This seems to be a problem of the Deutsche Telekom network. I asked them for a statement on this. I think this can therefore become closed. But if this is not fixed soon it might be good to document this problem somewhere.

The problem is currently present again. I made some measurements with an interesting result. There seems to be some kind of insufficient peering capacity when the download comes directly from eqiad and is not on some cache in Europe.

The problem seems to be fixed for now. The loading speed is not very fast but currently absolutely usable. At the time I created this report the respond times for the pbf files were around 30 to 60 seconds.

The loading speed is currently much faster than yesterday. I especially experienced the problem with the vector tile loading on my tool https://uploadmap.toolforge.org/protectedareaseu.html.

The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

I see the link on fully opened diff pages. But on RTRC (https://meta.wikimedia.org/wiki/User:Krinkle/Tools/Real-Time_Recent_Changes) the links are missing.

I looked at the edits made using the affected user rights manager gadget:

I think there should also be an incident report on this as a bug blocking the deletion of files could cause very serious problems if there is a file that needs to be deleted immediately. The legal team should also comment on this topic.

I think this is the same error which causes T348375: Commons removal of last remaining caption: Caught exception of type Wikimedia\Rdbms\DBUnexpectedError.

I just noticed that all last edits on audio files are affected by this. I tested this on https://commons.wikimedia.org/wiki/File:2019-08-17_Test_file_for_TimedMediaHandler_audio_captions.ogg with the following error codes:

I got the error again and again at the file page of an audio file but this time on a Wikitext edit.
https://commons.wikimedia.org/wiki/File:Javier_Milei_-_nombre_(ES-ar).ogg
When I click the revert button on the last edit I get the following error message: [f41e10bb-593c-4ddc-a499-f8af808578fa] 2023-10-08 18:41:16: Fataler Ausnahmefehler des Typs „Wikimedia\Rdbms\DBUnexpectedError“
Same for undo: [b3f94f11-495f-400e-aec5-7db8d7f0a33d] 2023-10-08 18:42:11: Fataler Ausnahmefehler des Typs „Wikimedia\Rdbms\DBUnexpectedError“
And also for manual removal of the added Wikitext: [2ed02a9b-1877-4323-9041-d6e93abab37b] 2023-10-08 18:42:45: Fataler Ausnahmefehler des Typs „Wikimedia\Rdbms\DBUnexpectedError“

Before the "Caught exception of type Wikimedia\Rdbms\DBUnexpectedError" message there is only some kind of hash number. But when I tried to get these number again I got no error message and the edit succeeded.

I see. This seem to be a problem with the testing environment.

I think this is not linked to the error rate but it makes the need for a fix more urgent. The Wiki Loves Monuments contests started today.

Are feature requests and bug reports on this project tracked here on Phabricator, on a wiki page or on Github?

I also get many 5xx and stashfailed errors on my current uploads using python requests library.

As this does not seem to be solved in the near future it might be useful to add a link to Special:EditWatchlist/raw to the GUI of the watchlist page.

Simple webserver restart in this case.

I tried to migrate my script. As it requires the requests python package I needed to create a new venv. I followed the Instructions at https://wikitech.wikimedia.org/wiki/Help:Toolforge/Python#Kubernetes_python_jobs but when running the command "chmod ug+x bootstrap_venv.sh" I get the response "chmod: changing permissions of 'bootstrap_venv.sh': Operation not permitted". I am logged in as the tool(become toolname).

I can confirm that I got many "Invalid CSRF token." errors when uploading.
The errors did pop up random after every upload attempt or only every hundred files. (I request new tokens for every file.)

I would like to have the German GeoNutzV (https://commons.wikimedia.org/wiki/Template:GeoNutzV) license added as an allowed license. It is basically the same as CC-BY.

Update: Now it works fine for me too.

Just opening a page using the tiles like https://maps.wikimedia.org itself in a browser and looking in the network analysis tool of the browser.

Many other limits are higher for logged in users or users with higher rights then for not logged in users. Would it be possible to do the same here?

I do not want to create a new task for this so I mention this here because it is very similar and some data might be double licensed with both of these licenses.

I think that should not be closed because the other task is for the general problem. This is only about the SuggestedTags tool.

Since about two hours I also have timeouts on API and webpage. (Location Berlin)
The Grafana boards also show low edit rates and API requests and HTTP Errors.

As I have the same problem here some information I can provide.

Little update: In the first report only some files where affected. Now this is happening to all of my files. (of course only of them having GPS data in the EXIF) Example

Maybe it was misunderstanding the browser only stops the tab to prevent a crash of the hole browser or even the system.
The problem seems to be a script, but I will check it with another browser.

I added the 2019 WLE list to the module.

In T216877#4978054, @Aklapper wrote:

As a workaround, does using Special:EditWatchlist/raw work?

I think i it themes fixed now?
So only as additional information (I do not know if it is relevant): When I uploaded the files the field for the caption in UploadWizard was the same type as the description field and not the one-line field like it is now.