RAWeb
RAWeb copied to clipboard
RetroAchievements
Achievement Inspector - Sorting Order Bug
This has been an issue for a while and I've brought it up a handful of times...
When changing the order of achievements in a set, I often run into an issue where several achievements get skipped when refreshing. It almost always happens when there's around 20 or more updates to the display order at one time. This is very frustrating for bigger sets and can result in a bit of a mess if it's not caught right away.
I'm assuming the issue is with how many requests are being made, in which case I think there needs to be an exception for this action.
Just did it again. I tried to do it to 28 achievements at once. 1-28. This is what actually got sorted: 1 2 3 4 5 6 7 8 9 10 11 12 XX <-- still 0 14 15 XX <-- still 0 17 18 19 XX <-- still 0 21 22 XX <-- still 0 24 25 XX <-- still 0 27 28
How are you doing this? Just 1 <tab> 2 <tab> 3 <tab> 4 ...? Even if the number of requests per second is limited to 10, that's some pretty fast typing.
Numpad and tabs. I type a bunch in and then refresh the page since that's what actually makes the changes... Right?
It's likely a throttling issue. The display order input area being modified causes a request to be made to update the display order. This happens when tabbing or clicking out of any input area after modifying it. So you are making 28 relatively quick requests to update achievement ordering.
@luchaos is it possible to reduce the throttling limit for this page or on the /request/achievement/update.php call itself.
Oh, so the issue actually is me typing too fast?
yup :)
is it possible to reduce the throttling limit for this page or on the /request/achievement/update.php call itself.
Throttling is done on the web server level atm. V2 will allow us to define rate limits for individual routes in code. I'd like to keep the current rate limits intact as they have to serve as safeguards for larger areas of the site. Adjustments for individual routes/scripts would just increase webserver configuration overhead for me temporarily for a not that pressing issue. With v2 we won't have to rely on catch-all configurations on the webserver level anymore.
One possible solution to this issue is adding a Save All button for this page, similar to what was recently built for drag and drop site awards. From a UX POV, I'm not sure how valuable saving on blur for each input field is, especially if it's causing users to bump into rate limiting issues.
