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…
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.
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
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.
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.
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.
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.
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.
