LuckPerms

LuckPerms

41.4k Downloads

Permissions rolling back/not saving

hutchy50 opened this issue ยท 39 comments

commented

I've been experiencing issues where a players rank is set or they receive a permission just for it to disappear later. After looking at the logs it appears in the actions log but doesn't save to the database. Using split storage, ranks and tracks are YAML, everything else is MariaDB, although the issue still happened with everything set to YAML.
SpongeForge 7.1.8
LP 5.0.73

commented

Logs and screenshots
https://hastebin.com/ibenefelom.sql - Debug of permission event
Images show actions logging the permission change, second shows that the users perms weren't updated.
Screenshot_1
Screenshot_2

commented

Can verify this issue happens to me as well

commented

Also having an issue with this as well...

commented

This has been happening for my server as well.

commented

Have you guys true installing this? https://ci.lucko.me/job/extension-default-assignments/ seems like it fixed the issue for me so far

commented

That would make it even weirder.

commented

The default database storage that ships with lp

commented

For me this issue was present when using both YAML and MariaDB. I will note that the first reports of this issue on my server was after installing GD and it was my first suspect with it's change to using meta data to store claim blocks. Since this issue happens somewhat uncommonly testing without GD on a test server may be difficult.

commented

This is occurring on two of my Sponge servers too, notably after scheduled restarts. Using the default H2 database storage option.

Like others here, I am using GriefDefender.
The issue only began after the 12th, when I updated LP from 5.0.55 to 5.0.78, but I also updated my GriefDefender at that time too (as the GD update introduced the migration of GD data to LP userdata).

SpongeForge: 1.12.2-2838-7.1.8
LuckPerms: 5.0.78
GriefDefender: 1.2.5-B16

I tried replicating the issues prior to this post, but it seems to be uncommon- as I've had a few users update their permissions via the donation store with no issue, and others who have contacted me with "Hey, my donator rank vanished" or "The extra /home's you granted me have vanished".

commented

Taking it this was never looked at? Still having this issue and no idea why. No error on startup. It rolls back a players group to what it was previously. Should I move to mysql or something?

commented

@VOrlando520 Are you running GriefDefender on your server? I noticed that @hutchy50 is and I am as well. Not sure if it could somehow be related.

commented

I took a look at @varnithian97 's Github profile, he is running GriefDefender too. Is it a coincidence that all of us with the issue seem to be running GD?

commented

Yes I use griefdefender as well

commented

Everyone that uses GD, could you try to see if the issue persists without GD?

commented

I can assure you it is not GD. I'm running the following on my production server with none of these issues.
SpongeForge: 1.12.2-2838-7.1.10-RC3994
LuckPerms v5.0.73
GriefDefender 1.2.6 B1

I use solely MariaDB for storage.

Edit: Clean new test server using only same versions above, but using all defaults(Would be H2 storage in LP) does not reproduce this either. I set permissions on my user, and created a new group and gave it permissions, switched my user between them and logged on and off, and restarted the server and all permissions stayed as they were set.
Something else is messing with permissions, and it's not LP or GD.

commented

I'm not claiming it is GD. I just want to find out if there's a connection.
It could very well be that it's a bug in LP that only triggers with GD present (as they use special permission magic).

Also what storage types is everyone using?

commented

As an update. This morning I had two further player reports of LP related issues:

The first was that GD 'bonus claimblocks' had seemingly vanished, whilst I have logs of them being distributed correctly via /acb

The second was a player who had a rank set on the 13th and has played every day since- just for his permissions and prefix to vanish. Interestingly, he still had the group.rankname permission from past purchases, just not the one from 4 or so days ago.

This is rather troubling. I can only assume GD is somehow involved given that the issues only began when I started storing GD data in LP.

commented

As an update. This morning I had two further player reports of LP related issues:

The first was that GD 'bonus claimblocks' had seemingly vanished, whilst I have logs of them being distributed correctly via /acb

The second was a player who had a rank set on the 13th and has played every day since- just for his permissions and prefix to vanish. Interestingly, he still had the group.rankname permission from past purchases, just not the one from 4 or so days ago.

This is rather troubling. I can only assume GD is somehow involved given that the issues only began when I started storing GD data in LP.

Yup had the same issue this morning as well. Debating on rolling back to an older version of gd just to verify that gd is indeed the issue

commented

@PulzHF I've now confirmed, the issue still happens for me on 5.0.67

commented

We are getting that issue from time to time aswell. It happens only on adding a group to a player after a /rankup. When a restart happens some hours later, the added group is gone.
But that is pretty much the only big permission operation on our server, so guess it can happen with meta etc and group removing aswell.
Need to say, that we got that issue with one of the latest LP4 builds and all LP5 builds. But as it just happens every 3 weeks or so, I wasn't worried and didn't reported it

commented
commented

Maybe a race condition when calling. user.save() too fast in a row. The new call could overwrite the old one. Guess GD isn't the issue itself, but it shows the issue that saving has. (If fast saving causes race conditions)

commented

I wonder if @bloodmc has any input on this

commented

I wonder if @bloodmc has any input on this

He does and is actively talking to Luck about it.
He said:

yea reported to Luck, ill see what he says
ill see if Luck can provide a debug build showing trace for meta unset
because it doesnt make sense how GD is causing meta not even related to it to be lost
also the strangest part is, its random
which tells me its most likely related to race conditions in caching
GD doesnt handle LP storage but it does call saves due to issues it has had in past

He is currently working on a potential fix.

commented

Good to know. I wasn't aware that Luck knew... I just pinged him on Discord about it xD

commented

Edit: As below, apparently isn't the case.
After discussing this with a few people on the GriefDefender discord, user WhatsTheBadNews#1060 believes that downgrading to 5.0.67 resolves the issue.

commented

I am also having the same issue, I am using MySQL database and connected 6 servers together but when I import a permission file it imports successfully and also saves everything but after some time it will randomly remove some permissions out of no where.

commented

Sorry for the late reply here, I've had a busy couple of weeks!

Definitely seems like GriefDefender is the common cause here - unless anyone can say otherwise??

I've just replied to @bloodmc on Discord, hopefully a solution can be found. :)

commented

I am not using the GriefDefender Plugin but still facing same issues!!!

commented

@AshuGuptaGamer I mentioned to you on Discord that this issue does not apply to you. Your problem is probably something else. Either open a new issue or respond to people when they are trying to help you on Discord.

commented

Since switching to the griefdefender-sponge-1.2.6-PERM-TEST1.jar a week ago I've not experienced this issue.
Blood said this one 'disabled cache in LP provider'/'disabled save call' but he could tell you better than me.

commented

When that GD change actually helps, its a lp issue in cache/save management that needs to be fixed

commented

This issue should be resolved in commit bloodmc/GriefDefender@c1acd88

commented

Ah forget my last comment, GD used its own simple cache which caused it. Will give that build a try

commented

So is this a LP issue now? Like LP doing wonky stuff with saving data?
Or is a GD issue? Like the cache overriding changes LP applies itself?

commented

GD cache overwrote already made changes. Not a lp issue. But please leave it open a bit to let other GD users to confirm

commented

I can't close it anyways. ;)

commented

Can anyone else confirm?

commented

Assuming lack of reply is positive - closing for now.