MySQLite drops an error for seemingly no reason

[Shigbeard]

Description of the bug

On a clean vanilla setup using tmysql4 for database shit, if a player joins and there is nothing in the darkrp_player table, mysqlite drops an error regarding a missing column/key.

The query it tries to run is DROP INDEX rpname ON darkrp_player which it reports back with Can't DROP 'rpname'; check that column/key exists

How to make the bug happen

1. Set up a blank database for a DarkRP server. I named mine darkrp with a user by the same name, permitted on any host identified by a password, and given full access to its database and nothing else.
2. Set up a vanilla DarkRP server. For reference, the only changes I made were a handful of hand written jobs, a weapon pack, and modified the configuration in the darkrpmodification addon. Configure the server to save its data via tmysql4 to the database setup in step 1.
3. Start up the server, and attempt to connect. Some time between the PlayerConnected hook executing and the PlayerInitialSpawn hook executing, the error will appear.

Lua errors

[ERROR] lua/includes/modules/hook.lua:84: gamemodes/darkrp/gamemode/libraries/mysqlite/mysqlite.lua:280: Can't DROP 'rpname'; check that column/key exists (DROP INDEX rpname ON darkrp_player)
  1. v - [C]:-1
   2. unknown - lua/includes/modules/hook.lua:84

There are no earlier errors to report.

Why the developer of DarkRP is responsible for this issue

This is a vanilla install, with all files fetched directly from github using the git clone command. No changes to core files have been made, and the only present addons are a weapon pack, FProfiler (because I'm still setting shit up and I want to know what won't make the cut as I go), and the darkrpmodification addon.

The only changes I made to the config are standard ones including replacement police, mayor, and hobo jobs. No additional addons have been installed yet. However, just to be sure, I did a git diff on the gamemode, and it returned nothing, implying there is no difference (iirc, im not the best at git cli).

As such, the problem clearly doesn't lay in my hands, nor in the hands of a 3rd party addon developer. Thus, by process of elimination, the only responsible party remaining is the DarkRP development team.

And yes, the only reason why I'm being this detailed is because of the usual children that think pasting an error in the issue will make everything magically work for them without having to put any effort into it.

And I refuse to step foot in the DarkRP forums because of those children.

[end360]

Have you tried removing the table so DarkRP has to make it again? It might've just been a random glitch when DarkRP made the table.

[Shigbeard]

No, because it functions normally otherwise. It's just an error that could be easily avoided by checking if there is an entry in the first place before attempting to remove any entry.

[FPtje]

The check is there. It's running a migration from a previous version of the table to a newer version.

The strange thing is that you say you've done a clean install. There should be no migration. The line running the query is here: https://github.com/FPtje/DarkRP/blob/master/gamemode/modules/base/sv_data.lua#L261

The version is loaded here: https://github.com/FPtje/DarkRP/blob/master/gamemode/modules/base/sv_data.lua#L112

So the version is initially 0. That means a migration will be performed.

The thing is, though, it immediately writes the database version to the database, even before doing the migration. That means this should be a "first time booting" thing.

Does the problem still occur when you restart the server?

[Shigbeard]

No, the issue never repeated itself.

Would this migration occur in the event that in a previous boot attempt, the DarkRP server attempted to setup to a MySQL server but was denied access? We had an issue with MySQL refusing access, which we resolved by removing some stupid default user accounts that allow anyone anywhere to access my data without a username or password.

[FPtje]

The issue never repeating itself would be precisely what I'd expect. The fix should be easy.