8000 Data being reverted to a previous save when shutting down servers · Issue #45 · Kampfkarren/Roblox · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Data being reverted to a previous save when shutting down servers #45

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Intrance1 opened this issue Sep 2, 2019 · 9 comments
Closed
Labels
Milestone

Comments

@Intrance1
Copy link

After doing some testing, I think what's happening is when a game server is shutdown, the player's data is reverted back to the data received from the initial :Get() when the player joined the server, ignoring any changes made to the player's data while in the server.

@Kampfkarren Kampfkarren added the bug label Sep 2, 2019
@Kampfkarren
Copy link
Owner

Can you try this and see what happens (best if it works on a slightly modified baseplate):

  • Join server
  • Change data in some way so that it actually saves
  • Shut down all servers
  • Quickly join back
  • Observe your data is the old data
  • Do NOT change your data
  • Leave, it won't save if data isn't changed
  • Join back later

What data do you get? Old data or the data from when you shut down? My theory is it's still saving by the time people rejoin.

@Intrance1
Copy link
Author

I followed the steps and got the old data.

@Kampfkarren
Copy link
Owner

@Intrance1 That's strange--and it says in the console it didn't save because of unchanged data, correct? DataStore2 runs code on BindToClose, so there could be something incorrect there.

@Intrance1
Copy link
Author

There's nothing in the log after the game is shutdown. I'm not sure if messages continue to be posted to the console after the server is shutdown. The message could be posted after I'm kicked from the server and that could be why I don't see anything in the console.

@Kampfkarren
Copy link
Owner

Can you see what happens when you add this somewhere in your code:

game:BindToClose(function()
    dataStore:Save()
end)

I wonder if it's a BindToClose problem or a DataStore2 problem.

@Intrance1
Copy link
Author
Intrance1 commented Sep 3, 2019

That worked. I shutdown the server and "saved key" outputted in the console, then rejoined and had the correct data.

@Kampfkarren
Copy link
Owner

Strange, that means it must be an issue with how DataStore2 specifically implements it. Not so coincidentally, there's also no unit tests for it.

Here's the relevant lines:

Roblox/DataStore2/init.lua

Lines 619 to 644 in 56a0d27

local event, fired = Instance.new("BindableEvent"), false
game:BindToClose(function()
if not fired then
event.Event:wait()
end
local value = dataStore:Get(nil, true)
for _, bindToClose in pairs(dataStore.bindToClose) do
bindToClose(player, value)
end
end)
local playerLeavingConnection
playerLeavingConnection = player.AncestryChanged:Connect(function()
if player:IsDescendantOf(game) then return end
playerLeavingConnection:Disconnect()
dataStore:Save()
event:Fire()
fired = true
delay(40, function() --Give a long delay for people who haven't figured out the cache :^(
DataStoreCache[player] = nil
end)
end)

It's a bit weird, but the gist of it is:

  • When the player leaves (ancestry changed and they're no longer in the data model), set a "fired" flag to true after it has been saved and fire an event.
  • On BindToClose, if the player hasn't successfully saved yet (the "fired" flag), wait for them to save.

This logic makes sense to me, so I'm not sure why it isn't working. While we could just call :Save() twice, this would fire two requests to save the data, which would add additional overhead.

@Intrance1
Copy link
Author

So I was doing some testing with the playerLeavingConnection and I think the problem is with the AncestryChanged event. I replaced it with a PlayerRemoving event and that worked.

@Kampfkarren
Copy link
Owner
Kampfkarren commented Sep 4, 2019

That must be it, the AncestryChanged patch is recent: 620688e

Thanks for you research! I'll fix it when I can unless you want to make a stab at a PR (that also fixes the memory leak the previous version had).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants
0