Page MenuHomePhabricator

wikibase.cloud 429s to Special:EntityData on a page load that succeeds leads to non loaded editing tools
Open, Needs TriagePublic

Assigned To
None
Authored By
Addshore
May 6 2026, 10:30 PM
Referenced Files
F79971294: image.png
May 6 2026, 11:06 PM
F79970954: image.png
May 6 2026, 11:06 PM
F79968497: image.png
May 6 2026, 10:30 PM
F79968472: image.png
May 6 2026, 10:30 PM

Description

This page load shows a 429 on the Special:EntityData call from the wikibase UI itself

image.png (3,839×2,010 px, 369 KB)

This results in none of the statement editing functionality loading on the page, and it doesn't really tell the user at all that this is what is happening
For me, this resulted in me refreshing the page a bunch of times (more requests) to try and get it to work (eventually getting a 200) for the Special:EntityData call, and allowing the editing tools to load

image.png (3,815×1,990 px, 380 KB)

I imagine that the wikibase UI itself could better handling for 429s for this call to special:EntityData
I also imagine that the rate limiting might be able to have better behavior for some referrers, or in the case valid cookies are present etc?
However, I'll leave this ticket as is for now...

Event Timeline

I tried reproducing this on wikibase.world and have hitting Special:Random just 3 times I got a 429 for the Special:EntityData call.

I then tried a totally fresh site for myself after a min, being https://diglearning.wikibase.cloud/
I started on the main page, and hit Special:Random twice, and on the second page load got a 429 for load.php which stopped the page from loading correctly

image.png (3,788×2,016 px, 489 KB)

This was probably partially "cheating" in a negative way as my browser cache was disbaled having the console open, so I tried again with https://labrhfairfillment.wikibase.cloud/wiki/Main_Page
Even with the browser cache disabled, it only took navigating to 4 pages to hit a 429 on Special:EntityData leading to the page being broken

image.png (3,821×2,143 px, 536 KB)

Seems like another case where we need to review ratelimiting (maybe we can substantially relax it for logged in users, users who pass Anubis already etc.)