
Temp group/permission sometimes does not apply
aaa8881 opened this issue ยท 3 comments
Description
Using Luckperms temp permission and group system quite often for booster-like system in game.
It is not common considering numbers of temp permissions given in a day, but definitely happens possibly lower than once out of thousand times.
setup: 1 proxy, 13 servers with Luckperms behind. mysql and redis enabled. db server is in diferent server machine, but all servers are connected locally. connection time is always <1ms.
- Everything is set up correctly. temp perm is given by accumulate. Server is generally not overloaded (happens in definitely not overloaded situation as well) , db speed is fine with no particular slow query, no server crash.
- temporary permission or group sometimes does not apply.
- Luckperm logs correctly that perm or group is given correctly.
this means I can find specific user with problem did earn perm by using /lp log userhistory.
- these permission or group is given by console using command and logged correctly in latest.log like this
[00:06:10] [luckperms-command-executor/INFO]: [LP] yochwan now inherits permissions from vip for a duration of 4 weeks 2 days in context global.
[00:06:10] [luckperms-worker-4/INFO]: [LuckPerms] [Messaging] Sending log with id: 34a71b66-bcc8-4c49-b0c2-da62b2ebc54d
[00:06:10] [luckperms-worker-5/INFO]: [LuckPerms] [Messaging] Sending user ping for 'yochwan' with id: eccc56e0-6c21-4d1d-a8cb-bb586c1809ac
- based on many player's description, failure happened right after perm or group is gained.
means player did not log out or changed server within proxy when failure happens. users usually check this quickly because many wants to know if their buff or group is correctly applied. It is unclear if it EVER succeeded to apply or not, but based on user descriptions so far, it seems like perm is never granted.
I really don't like claiming, something ain't work and I don't know how to reproduce, but this is some of that kind of problem, and I'm unsure what to collect more. I will provide any kind of information in need if requested.
Reproduction Steps
explained above
Expected Behaviour
explained above
Server Details
purpur 1.20.4
LuckPerms Version
5.5.10
Logs and Configs
No response
Extra Details
there are some weird behaviors I have found that may be relevant.
chat format prefix is based on player's current Luckperm groups.
For example, default group has prefix of [user] , and vip has prefix of [vip]
and it has been often found that [vip] players sometimes are shown as [user] , so chat history looks like
[00:00:01] [vip] signition : hey man
[00:00:02] [vip] signition: how you doing?
[00:00:03] [user] signition: weather is hot
[00:00:04] [vip] signition: I love icecream.
, so it is clear that user is not meant to lose group or permission, but he loses his group status for short period of time as if it requires some sort of sync time. I suspect this may be related to current weird issue.
still happening,. and it seems happening recently, so may be related to recent bungeecord changes
- NodeRemoveEvent happens when permission is cleared.
- happens frequently on permission that are added/removed very frequently by many players.
When you say NodeRemoveEvent happens on clear, do you mean that when the user is supposed to (for example) get VIP rank, they get a NodeRemoveEvent instead, or that the NodeRemoveEvent always works when the temp permission expires?
I'm curious what your method is for setting/removing the temp permissions? It's possible that you have a system where a user double-clicks something in a GUI and the GUI plugin sends an add-remove-add command in sequence, or something fishy like that happens when the temp permissions are set. Not that it would have to be a GUI, just that the code adding or removing these perms isn't airtight.
When you see a player going from VIP to User to VIP, check the logs: do you see what the source is for that change at the same timestamp? Usually these problems are one of two things: LP is being told to do this by another plugin, OR the database connection gets interrupted or is slow, so LP can't know what it's supposed to do until the DB updates.