I want an API where I can tell the server “Update this key with this data in the event that the server closes”.
OnClose doesn’t work because I may run out of requests or the server may crash or some other nonsense. Calling SetAsync when something changes also doesn’t work because of the rate limit. I want a high-level safety feature that prevents my players from losing content that they paid money for.
Can’t this be averted by not returning PurchaseGranted until you’ve verified the DS request has succeeded? If you don’t return it, the player will be refunded. If it takes too long for them to be refunded or it’s not communicated enough that they were refunded (rather than ripped off by your game), that sounds like an issue with refunds rather than DataStores.
I can’t have purchase times and load times bogged down just because people are buying stuff. This also emphasizes the problem of a player leaving and not having enough requests to instantly store their data, so they can rejoin and have old data.
Re-read what I quoted and responded to. It was taking player money but not giving them the item – nothing else about DataStores.
This can happen due to countless scenarios that aren’t even limited to purchases or switching servers. For instance, I might want to update the player’s data from Studio while they’re playing at the same time. When the server they’re in goes to update the data, what then? Does it completely overwrite my changes? Do my changes overwrite the player’s items they’ve obtained since I updated their data?
Issues like these will always crop up with the current API, but rather than an “emergency” key that’s limited to just the cases you’ve mentioned (and will likely introduce another request type in DS limitations), I think we need better in-house version control for overcoming any sort of version discrepancy.
This isn’t a failsafe catch-all to prevent all data loss. This is just to prevent data loss from edge cases where the developer is unable to save the data themselves.
I don’t want to give people refunds and then try to explain to them a feature that roblox itself doesn’t even explain. I want my data to be saved.
What happens when the server shuts down or crashes? The emergency requests wouldn’t function at that point. You’ve mentioned that this doesn’t prevent all data loss, but it also doesn’t prevent all edge cases where we’re unable to save data ourselves. Hoping data automatically saves with this emergency queue is a bad idea to begin with. If you want any sort of reliable transaction, you need to rely wholly on certainties and not on hope at all.
Again, this is a refund issue – not one concerning DataStores. And to be honest, it’s not really a refund – the player’s money is just put on hold until the purchase succeeds. This is how any sort of reliable exchange works. If you don’t want to explain “refunds” to players, request that ProcessReceipt take the ROBUX out of holding and give it back to the player immediately after ProcessReceipt returns anything but PurchaseGranted or stops responding (e.g. server shut down).
The issue isn’t with DataStores/MarketplaceService – it’s with your outlook on transactions.
That’s the whole point of the emergency requests. They would be designed so that a roblox server crash wouldn’t stop data from being saved. Obviously if the hardware or something lower level breaks then there’s a problem, but that doesn’t happen nearly as often as the developer simply running out of requests.
I don’t know why you’re talking about handling every single data loss case. Obviously if you turn my argument into that then I’m wrong, but that’s not what I’m saying. Right now if you run out of requests and the server shuts down you are boned. There is no two ways about it. This is a problem that needs to be dealt with.
I also don’t know why you’re talking about refunds. I have no interest in losing money because roblox doesn’t provide a proper failsafe API.
There’s nothing that you can do in the event of a server crash. One a server crashes, it stops working, and your emergency save aren’t going to work. The only way to prevent this is to periodically save these keys so that even if the sever crashes they’ve already been saved x minutes/seconds ago. If that’s your plan, how is this a good idea? Now you’re saving the same key twice.
How does this help? All you’re doing is adding a special pool of requests (that will doubtlessly also have a limitation). What happens when you run out of emergency requests? Why can’t you manage your requests so that you don’t run out of them to begin with? Are you doing something special that uses tons of requests?
I made a game called “Space Evaders” w/ 100 max players. my friend and I wanted to see how it’d handle 100 players, so we filled up a server in seconds. The server crashed (somehow) shortly after running out of DataStore requests from loading 100 players data at once at the start of a server.
My data system uses my webserver as a backup. All data is duplicated to my webserver. If you join and your data doesn’t load from the DataStore, it uses httpservice to get the data from my server. This makes it so even when datastores go down, my game still loads/saves just fine.
This was the first time that they had played the game, so it sent a request to get the data from DataStore, saw it didnt exist, tried to load it from my website.
1 DataStore request x 100 = 100 requests at the start of a server = ran out of requests (I assume)
1 HttpRequest x 100 = 100 stalled requests at the start of the server = server ended up crashing (I assume, other things send Http requests occasionally so it was likely more than 100)
Somehow, this made the server crash. The game is 99.9% client-based. The server handles loading data only. All players lost connection and the server hung for about 2 minutes. The play button resulted in error 17.
This happens every single time. The server can’t handle loading everyone’s data so fast, which doesn’t seem like an issue on my end, more so ROBLOX’s. Sometimes the server can’t even make it to 47 before crashing.
Edit: on second thought this may not be 100% relevant to the thread, but in my mind it was lol. Maybe something like this would allow everyone’s data to load and not crash the server.
Well, the server never even got a chance to save data.
It crashes while loading due to so many people joining so fast. All I’m doing is :GetAsync (DataStore) and :PostAsync (HttpService).
The server doesn’t handle anything but data, so loading data 100% has something to do with it.
Edit: I’d like to think something like this would solve it. I have no clue how I’d go about addressing an issue like this on my end at the moment. I don’t like the current DataStore system and have been thinking about swapping to my webserver to replace datastores completely due to the limitations and errors that occasionally happen.
It won’t. Proposed solution would only affect data loss – not data loading – in your case there’d be no difference. What you’re experiencing is still a nasty issue though that it’d be great to see fixed.
The easy solution is just to not send such a substantial amount of requests in that short time period. Update your DataStore interface to automatically queue requests and only allow through x requests per second/minute. Players may have to wait a little for their data to load, but it’s better than not being able to play the game at all. Even if ROBLOX fixed the crashing, you’d still be running out of requests and you’d end up doing the same thing (waiting some time to load the data).
I don’t have to legitimize my request by describing how it would be implemented. If everyone who wanted something had to implement it themselves then nothing would ever get done. I’m a developer and this is what I want because of problems that I’m perceiving. I’m not going to describe every last implementation detail to you.
If you’re only stating a problem and that you want an (unspecified) solution in general, yes you are correct. If you are suggesting how that problem should be solved, you should be prepared to discuss the feasibility of your suggestion and potentially make amends to it if the need arises. Feature requests are handled on a topic open to posting exactly because this kind of discussion needs to take place.
If you don’t discuss your planned implementation with anyone else, you’re missing out on catching issues in the early stages before spending effort and resources implementing it only to find out it won’t work. Unless, of course, you like the idea of your feature potentially idling in “awaiting release” for half a year.
Would be very useful if it allowed us to delete a key (e.g. server data) when a server closes. but we don’t even have DeleteAsync or UpdateAsync(key,nil) yet, so yeah…)
This discussion got very toxic, but I’ll try to tread lightly, esp. since I don’t agree with its utility.
So it seems the reason you want to wait before writing a key is because you’re worried you’ll run into limits if the user keeps jamming the “buy this item” button. Wouldn’t a good solution, then, be to increase the limits?
I’m worried “write-on-exit” keys would just add to API bloat, seeing as we can write on exit by writing within OnClose.
This doesn’t solve the problem. The problem is that there is an edge case that exists where the user’s data doesn’t get saved and I can’t do anything about it, but roblox can. Even with a higher limit the edge case would still be there.
