Why won't my datastore saving system retry properly after failure

Help and Feedback Scripting Support
#22

I thought it could be that actually so how long do I have until the game shuts down? And is there a way to fix this then? To give it a longer delay and let it retry fully?

#23

The problem is that the game closes after the player leaves. Your code should work. However, you should use something like this solution below with BindToClose to keep the server from shutting down. The official documentation has a code sample for saving player data before shutting down.

#24

connecting to a bindtoclose i assume but im not sure.

#25

ahhh I guess my assumption was right?

#26

I was given advice not to do that though a while ago because they said if your saving system works a bind to close might cause more incovenience or something.

#27

yeah, you are really our forgotten past aren’t you. you brought back the bind to close method which was something from the past.

#28

this might help

#29

Why does he use ipairs though to loop through the players in the bindtoclose method?

#30

If you are testing in studio it doesn’t actually wait til all threads have finished (or 30 seconds) as it assumes you might want to get on with something else!
Add a bind to close with a task.wait(20) and it should let the thread complete.

#31

because the player’s removing function stops working as the game shutdown

#32

I thought it might be because ipairs doesn’t continue to loop through when it finds a nil value possibly preventing error?

Also how does the player removing function not working link to using ipairs?

#33

I was told by the same guy in a different topic not to use bindtoclose

#34

So should I get rid of the retry system on the player removing event and move it into the gamebindtoclose?

Also what do you mean by the task.wait(20)? Can you give some code examples please?

#35

Bind to close and player removing run at different times.
Anytime a player leaves the game you would probably want to save their data, and would likely have time to retry multiple times.
However if the server closes for another reason, you’ll probably want to try and save everyone’s data then as well! Only issue is the players might not be ‘removed’ triggering the player removing event.

Tldr, save and retry for both player.removing and bindtoclose

#36

I assume the OP of the that just did it out of preference and since it’s a normal array used it instead

1 Like
#37

Okay, but does taht mean that I can’t make the delay longer on the player removing event because it won’t retry all the times?

#38

From memory you get 30 seconds once bindtoclose is triggered, so you can run retries fine, but it will depend on how many people are in the server and how fast you can push through the calls and what else you might need to run.
Most likely you could just keep retrying until the server shuts down for bind to close.

(The task.wait(20) in bindbto close was just to keep the studio server from shutting down which would prevent the retries from completing)

You could try something like this:

local serverDown = false
local function savePlayerData(player)
    local retryLimit = 5
    local retries = 0
    if serverDown then
        retryLimit = 30
    end
   repeat
    -- code for saving with retries
    until success or retries >= retryLimit
end
Players.PlayerRemoving:Connect(savePlayerData)
game.BindToClose: Connect(function()
    serverDown = true
    for i, p in game.Players do
        task spawn(function() savePlayerData(p) end)
    end
end
#39

I would probably just retry until the call succeeds because why would I risk throttling it?

#40

But my question is then, can I just retry with task.wait(1) on player removing event or no?

#41

Yes. You can. However, if the datastore is unresponsive for 5 seconds and your retry limit is 5 then the data won’t save. So this is why you would slow down the request rate.

Also if the retry rate is too high, and the data save request is malformed (so would never save anyway) it’s a lot of unnecessary calls over time.