aromaa / platformracing3 Goto Github PK

At the moment how the caching works on UserManager is flawed due to not taking account that async methods could load older versions of the user and caching them due to possible delays or when the data was updated the same time and the other tasks updated the cache faster and dismissing the new data.

This is not major issue due to how player data loading works on login, they are requested from the database itself and all updates like add exp are handled inside the database and being returned by it and updated to the player data

The Common project has static classes to manipulate the database with static database connection. This was bad design choice from the very start and now has grown to be the biggest pain in the ass. This should be changed and also split the classes to smaller pieces by at least using partial classes.

At the moment PrivateMessageManager which handles loading, creating and deleting private messages on database level does not have any type of caching, this could potentially overload the database and should be high priority.

This can be easily achieved as we don't really need to "update" the cache and only add and remove things. Pretty straight forward.

At the moment the LevelManager which handles level loading, saving, updating and deletion on database level does not have any type of caching, this could potentially overload the database and should be high priority.

This hasen't been issue due to low player count not effecting it that much and due to small complexity it provided hasen't been worth enought for me to implement it

A lot of players are experiencing this issue when trying to log in, while a minority are still able to log in.
-Mymsm is unable to log in at all
-ProClifo was able to log in for some time but then was disconnected by an error (idk if it was the same error, probably not)
-I (Nostalgia in-game) have been able to log in perfectly fine without any issues

I did some digging on this issue and this is what I'm sure of so far:

1. The evil aliens error only appears when the IsLoggedIn checked doesn't return XML data.
2. This currently can only happen if await UserManager.TryGetUserDataByIdAsync(userId); (found here) returns null
3. The only way that line can return null is if return DatabaseConnection.NewAsyncConnection((dbConnection) => dbConnection.ReadDataAsync($"SELECT u.id, u.username, u.permission_rank, u.name_color, u.group_name, u.total_exp......................WHERE u.id = {userId} GROUP BY u.id LIMIT 1").ContinueWith(UserManager.ParseSqlUserData)); (found here) returns null
4. This can only return null if either the query syntax is incorrect (which it isn't because some users can still log in) or if the callback function UserManager.ParseSqlUserData (found here) returns null.
5. That callback function can only return null under 2 circumstances:
   A. The query errors. This would cause the UserManager to log the error (UserManager.Logger.Error($"Failed to load {nameof(PlayerUserData)} from sql", task.Exception);, found here), so you should be able to test for this possibility fairly easily.
   B. The query returns nothing. Empty result. This would not cause any errors to be logged, but would cause this callback function to silently return null, causing the evil aliens error. I would suggest logging this possibility (caused by reader?.Read() ?? false being false (found here)) and asking users who are known to have this issue (Mymsm) to log in, and see if this possibility is logged.

This doesn't explain why some users had their database entries messed up in the first place, and it doesn't explain why users who are able to log in (such as myself) don't have their new campaign times saved to the server. This also doesn't explain why users who are able to log in (such as myself) still have certain parts and hats that they're not supposed to have due to the campaign times being changed. Those are probably results of some code elsewhere being messed up, but are outside of the context of this issue.

I don't have access to logs or databases or anything like that so this is pure speculation, but I'm guessing that when you either updated the campaign times or added the new domains, you changed something in the database (whether manually or via code) that causes some users to have one structure for their entry and other users to have another structure.