For a recent project I’ve wanted to see a list of available usernames, but I came across a problem. When I checked to see if a certain string (or username) was already occupied by a user it gave me incorrect results.
Below is a extremely simplified version of my code (that only checks usernames with numbers) that I’ve put together for an example:
local Players = game:GetService("Players")
cache = {}
function getIdFromUsername(name)
local id
pcall(function ()
id = Players:GetUserIdFromNameAsync(name)
end)
cache[name] = id
return id
end
for i = 1, 1000 do
print(tostring(i+100))
print(getIdFromUsername(tostring(i + 100)))
end
The function adds 1 to a consistently increasing number which is then put into a string and checks if it is a taken username. If it returns with a userId than that username is taken; if it returns nil than that username is not taken.
It all runs smoothly and as intended until at about 400 trials. At around the time it checks the username “400”, all other usernames after that return as nil. In the actual program it does the same thing at around that point. Feel free to try this code out for yourself to see what I mean.
I’ve also tried to add a wait in between when it checks the username, to see if I was requesting more data than roblox could send at a time, but that didn’t seem to work.
You have likely exceeded the maximum number of requests for the service, seeming as its wrapped in a pcall the error saying that the service has been exceeded wont flag.
To verify this you should add a delay on the 400th one (I’d say at least 10 seconds), see if that amends it.
Everytime I run the program, it seems to break at a different place. I put in a
if i == 350 then
wait(10)
end
before printing the results. I changed nothing else in the script and it returned everything as nil (even before 400). I’m not sure how this affected the rest of the script, but it certainly didn’t work.
I’ve done my own benchmarking on the async APIs that the Players service supports, and very liberally speaking, Players has 300 (iirc) async requests per minute before throttling begins. Once you begin throttling, you only receive about 6 requests per 6 seconds (or something like that), which would negate waiting even 10 seconds before allowing the next batch to go.
Due to these constraints, @TheTypicalDoge, it means that if you never wanted to throttle, which you should never want to, you can only make an async API call every ~0.2 seconds for a total of 5 calls per second.
I’d up that number and wait longer than 0.2 seconds, maybe wait(1/3) per call just to be really conservative, and max, only do 250 requests per minute instead of the total projected 300.
In my projects that could potentially use multiple different Roblox-supported async functions, I’ve created an AsyncRequestService manager to manage the async API budget using Promises. I even lower the total benchmarked available calls per minute number because I just never want to see the scenario where I’m having to wait 6 seconds for the number of available calls to update from throttling.
Honestly, your use case is pretty severe - the point of what you’re doing is hingent upon using GetUserIdFromNameAsync, so I see why this may not be the best option - it’s what I’ve had to come up with for myself.
Anyways, hope this helped! You can fiddle around with the numbers yourself to get the right balance between return speed and not throttling.
I should caution you that I actually haven’t benchmarked this service’s async request per minute limit, so I don’t know all of what it’s capable of. In-fact, I only discovered the method through sludging through and reading @Maximum_ADHD’s increasingly awesome API dump.
I’d stress test it by just sending a ton of calls without pcalls to see how many it can do before it starts hanging and taking longer.