Skip to content
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

bug: IsDisposed on the player can be falsely set to true #1598

Open
1 task done
AlexVild opened this issue Oct 7, 2022 · 1 comment
Open
1 task done

bug: IsDisposed on the player can be falsely set to true #1598

AlexVild opened this issue Oct 7, 2022 · 1 comment
Labels
bug Something isn't working needs verification Pending confirmation that the bug exists by another user.

Comments

@AlexVild
Copy link
Contributor

AlexVild commented Oct 7, 2022

Description

Due to async logic, it is possible for a player to be logged in such that their server entity's "IsDisposed" property is set to true. This can result in weird behavior, such as not being able to send out party invites.

Steps to Reproduce

This is very hard to reproduce. I only think I stumbled across it because I have a more mature project, and saving to the DB can take more time.

That being said, the core problem can sometimes be replicated by:

  1. Turn on multiple game character support in the server config
  2. Login is one character
  3. Login as another, for validation purposes
  4. With the first character, go to the character select screen from the escape menu and try to, as quickly as possible, re-enter the game
  5. if done successfully, you will not be able to send party invites to the other player, as the client's player entity is marked as disposed to the server.

This problem exists because, at logout, we use the DbInterface's pool to queue a work item:

public void CompleteLogout()
{
    User?.Save();

    Dispose();
}

Which does the marking of IsDisposed.

However, since this is in the DbPool, it is theoretically possible for a player to log back in while the pool is at work, and the pool may complete its job after the player logs back in.

Version with bug

7.1.22

Last version that worked well

Unknown, probably before the DbInterface pool

Affected platforms

I was not able test on other platforms

Did you find any workaround?

No. Perhaps we could not allow the player to log back in until their previously logged out-of entity has been disposed.

Relevant log output

No response

Duplicate Bug Check

  • This bug report is not a duplicate to the best of my knowledge.
@AlexVild AlexVild added bug Something isn't working needs verification Pending confirmation that the bug exists by another user. labels Oct 7, 2022
@AlexVild
Copy link
Contributor Author

Panda:

  • When the logout method starts, the user should not be allowed to make changes until the logout method is finished
  • At logout start, add the playerId to some concurrent dictionary that references players that are being disposed
  • Move most of the Logout() method to Dispose()
  • After complete logout, remove the player from the list of disposing/saving players
  • Do not allow login of any of a User's characters while a character is saving
  • Potential new screen for "Saving character, please wait..." if any of a User's characters are being saved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs verification Pending confirmation that the bug exists by another user.
Projects
None yet
Development

No branches or pull requests

1 participant