Vault

Vault

7M Downloads

Concurrent Mod Exception - Vault adding new permission on startup.

JamieSinn opened this issue · 19 comments

commented

Vault doesn't automatically handle API calls in a thread-safe manner. You'll need to make sure you are performing operations in such a way. IE: don't add permissions while the permission system is being initialized during startup. Make sure you wait for all plugins to be loaded before doing any modifications.

commented

None of my plugins use vault async. I'll poke this over to luckperms

commented

@JamieSinn - I believe the issue is adding permissions during plugin startup. Plugins shouldn't be trying to do anything during server startup. They need to schedule a task for when the server has finished coming up.

commented

@JamieSinn - my bad, I misread the original notes on this. Not sure what's going on that changed in bukkit, but it apparently can't do permission recalculations anymore or perhaps the API changed. Vault is now erroring when adding permissions at startup to the base permission system, which is quite odd.

commented

Thanks, thrown this over to Luck, hopefully he has an idea.

commented

@JamieSinn - I've never used PaperSpigot. perhaps it's an issue on their end? I've never seen the method that I'm using fail.

commented

@aikar @JamieSinn @andrewkm - any chance you can test that you don't have the issue on just spigot? I have a feeling this issue is a paperspigot issue and not Vault.

commented

Reverting Vault fixed all issue on my end.
EDIT: Incorrect statement.

commented

@andrewkm Not sure how that's possible, all of the updates within the last year have been to the POM, or a text output change.

commented

There is nothing in Paper that could of even led to this.

@Sleaker what gave you the idea it might be paper?

commented

@aikar - only seen 2 people report it and both reported using PaperSpigot, and my code hasn't changed in 3 years on how it interacts with the permission system? So I'm very confused. Was shotgunning to see if anything may have changed in how Paper handles permission recalcs.

commented

Still getting this. Seems random.
Latest one:

https://pastebin.com/raw/y1rFDemd

commented

Probably unrelated to the problem, but why are your version numbers Vault v1.6.7-b${env.TRAVIS_BUILD_NUMBER}

commented

Probably because I grab it from @md-5’s jenkins.

commented

@Sleaker - is it possible this is a race condition during another plugin hooking vault and getting perms, and it registering perms?

commented

@JamieSinn - vault uses a delayed synchronous task exactly because of potential issues with trying to do permission modification asynchronously. this is why I was suggesting that PaperSpigot might be at fault here, as A) the bug is not present to my knowledge in non-PaperSpigot implementations. and B) Vault explicitly isn't modifying the perms structure in an asynchronous way.

The reason why Vault was having to set the permissions in a sync task after startup was because it's load order: startup and bukkit didn't handle permissions properly in the plugin.yml for plugins that load at startup.

commented

I'm going to close this: unless someone can reproduce it on Spigot proper it's my belief that PaperSpigots messing around with the async and sync CraftSchedulers is the culprit here, see:

https://github.com/PaperMC/Paper/blob/master/Spigot-Server-Patches/0276-Improved-Async-Task-Scheduler.patch

Note: the link is just to show that PaperSpigot does actually modify areas of Spigot that could impact and cause this behaviour, it's not a proof that this is the actual patch in PaperSpigot that is causing this problem.

commented

Rip @aikar save us

commented

@Sleaker made some progress: PaperMC/Paper#1440
It is in fact paper exclusive, and it is caused by one of their commits.