Hey @24RightAngles Is the behavior finalized enough to know the answer to these yet?
The request will retry when the DataStore servers run into issues such as receiving way too many requests to update the same key (which really shouldn’t be happening in the first place). So, in otherwords, expect retries to occur when the DataStore servers throttle requests.
Lua errors, on the other hand are a little bit different. There are safety measures to queue up some requests that go over the DataStore request limit, but this is just a safety buffer and definitely is not something developers should depend on. Going over the request limit greatly increases the chance for instant failures for requests. But following the request limit guidelines will resolve nearly all of those issues.
The retry feature won’t use up the request limit on the client, but the DataStore servers will still be counting each requests.
Currently my DataStore interface takes a naive approach to handling limits and errors. If a request fails, it retries the next pass. If it fails 10 times, it discards the request as a Lua error. If three separate requests fail consecutively, it assumes a rate limit or temporary (just a hitch) / maybe longer-term (for a few hours) DataStore outage.
As a developer, I would like to explicitly handle limits as you suggested, but with current DataStore design that’s not possible:
- There is no documentation on the errors DataStores produce
- Error messages can change for any reason at any time, so I can’t hard-code those into the script
- I can’t tell how many requests I have remaining
Requests remaining:
I could manually hard-code DataStore limits into my script, but we’re not sure how DataStores work behind the scenes, so we don’t know if we add +1 request every 60/#requestsPerMinute seconds, or alltogether each minute, and even if there’s some clock we have to sync with to keep our request limit tracker accurate. To begin with, hard-coding limits was never a good idea:
We would need to have an API method to get the #requests remaining, as I don’t think the existing API would be backwards-compatible with returning the limits (everything except SetAsync already returns something), unless we maybe added it as a second returned value.
Ability to plan for errors:
The types of errors we get should be small in amount – we should keep the full error, but be able to distinguish from a simplified error set e.g. “RateLimitReached”, “LuaError”, “RobloxCPPError”, “RequestDropped”, “DataStoreOffline”, and maybe a misc/few others. We can’t plan around them if there are so many (undocumented) errors, and errors whose error messages can change for whatever reason.
10 Likes
Not entirely sure if this is what you’re asking for in the “requests remaining” thing, but you can get the number of DataStore requests remaining for all types:
http://wiki.roblox.com/index.php?title=API:Class/DataStoreService/GetRequestBudgetForRequestType
3 Likes
Try taking a look at the Datastore budget charts in the developer console. It uses the same numbers numbers as the GetRequestBudgetForRequestType that SteadyOn mentions. As for errors on Datastores…
http://wiki.roblox.com/index.php?title=Datastore_Errors
These will be returned as error codes accompanied by a message. You can reliably parse out the error code to handle those specific cases if you want. I wouldn’t try comparing against the messages since those are subject to change if we decide the messaging needs more clarity.
4 Likes
That page should be linked/included somewhere else, I did not know of its existence and it seems useful (cc @UristMcSparks)
1 Like
Hm, it looks like there’s an issue with the link, but if you search up “Datastore errors” on the wiki, you should be able to find the correct page.
I’ve added it as a small (but obvious) section to the “Data store” page now:
http://wiki.roblox.com/index.php?title=Data_store#Error_Handling
(which is what GetAsync/etc link to under their ‘See Also’ as “DataStore Manual”)
2 Likes
Was it ever turned on again? I’m coding a data system and for now I’m adding my own auto-retry system because there never was another statement regarding this
3 Likes
This seems like unusually bad communication from Roblox. I had no idea this feature was turned on at all, and by the looks of it no one added a message saying it was on.
No, this feature was shelved because higher priorities came up. When priorities realign, we’ll definitely take a look at this again.
1 Like
Just to clarify, datastore retries is currently not turned on.
1 Like
Hi there,
Is this feature still turned off, if so can we expect a ‘On’ soon 
6 Likes
Yeah could we have an update on this?\
3 Likes
We currently have some higher priority features to finish up first, but once we are wrapped up, we’ll see if we can fit autoretry datastores back into our queue.
3 Likes
Gonna bump this again, because I can query the property and it returns true, and thus I thought it was on. It’s documented on the RobloxDev site as a feature, which is very misleading if it’s not actually on.
18 Likes
It’s been 2 years, is this on yet? (Accidentally replied)
10 Likes
What if a player leaves and it continues to auto-retry getting their data? I’m not sure if this feature is the right solution. Perhaps some Async methods should have alternatives that use callbacks/connections.
2 Likes
I agree, I would probably prefer an article on the hub/forum where an engineer gives advice and code examples on effective retry/back-off mechanisms, or the callbacks as you suggest. Then we can choose to implement or forego it on certain requests without making all of the datastore API less predictable / harder to understand the behavior of requests.
2 Likes
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.