Request Rejected

A handful of player ids output a “Request Rejected” error with this line of code.

data:SetAsync(tostring(player.userId),save_data)

This means some players are never able to save their progress in-game. I have not updated the game in 5 weeks and I received the first report of player progress not saving 3 weeks ago. Since then, the number of reports per week has been growing steadily.

I had the same problem for Honey Madness. I had an OrderedDatastore, and switching it to a regular Datastore fixed the problem. Too bad I can’t make lists anymore.

Wow…OrderedDatastore would have been nice to know about before I wrote my leaderboard system.

So no, I’m not using OrderedDatastore for saving player progress.

Great… Another unexplained bug with DataStores…

I’m glad I’m a late adopter and I don’t have anything worth saving yet.

DataStore isn’t making Data Persistance obsolete, Data Persistance is almost making DataStore obsolete.

Only problem is that data persistence has that one in a dozen chance of wiping itself out from a sudden server crash.
If that was never a problem, I’d be still using data persistence.

[quote] Only problem is that data persistence has that one in a dozen chance of wiping itself out from a sudden server crash.
If that was never a problem, I’d be still using data persistence. [/quote]

This is why I use both, if there’s an issue with one, there’s a backup on the other.

[quote] I’m glad I’m a late adopter and I don’t have anything worth saving yet.

DataStore isn’t making Data Persistance obsolete, Data Persistance is almost making DataStore obsolete. [/quote]

That hurt me. :frowning: You can do much more with Data Stores; the biggest is being able to save data to the server and not to a random player. Yes, both services have known bugs but Data Persistence will never allow for the same functionality as Data Stores…

I guess I’ll use Data Persistence as my primary method for saving and use Data Store for backing up the data unless a roblox staff member can give me an explanation for why I am receiving this error.

I’m not sure why this is happening. After multiple Google attempts, you seem to be the only one with this issue. Some poeple said Request Rejected happens if the key is nil but that’s all that I saw.

Check your data size.

DataStore keys can only save at most 64K worth of encoded JSON data.

That also means that you should avoid convoluted compression such as storing binary encoded data, since it will actually increase the space taken to store it because it gets JSON encoded, and a single byte that isn’t a normal character gets turned into \uXXXX in the JSON string. If you wanted compression the best and easiest solution would be to Base64 encode the data into a string.

So, check how close those players are getting to the limit. Call HttpService::JSONEncode on some players data and print the length of the result out to somewhere you can read it. If people’s data is getting close to the 64K limit then you’ll need to solve that somehow.

you don’t get this error if your data is too big, you get “Can’t parse response”.

Thanks Stravant! The players that were not able to save were at the 64k limit. Do you know where I could find the code for Base64 encoding/decoding?

“The players that were not able to save were at the 64k limit. Do you know where I could find the code for Base64 encoding/decoding?”

You’ll be able to squeeze out probably 50% more space at most using a binary forma + Base64 Encoding it, but if you’re having players actually run into the limit you probably need to solve some structural problems first before you worry about the binary encoding, such as moving some of the data out of the main key into different keys. For instance, in our Age of Glory app we have saved replays. Those are obviously quite big, so we can’t save them in the main playerdata key. Instead, we assign each replay an ID, and then save it in a separate key, just storing the replayID in the main playerdata key.

I forgot to mention that there were some strange characters found in the saved data taking up massive amounts of space. That problem has been resolved and now saved data takes up at most 30K.