java.util.ConcurrentModificationException
	at java.util.ArrayList$Itr.checkForComodification(Unknown Source)
	at java.util.ArrayList$Itr.next(Unknown Source)
	at betterquesting.questing.QuestInstance.isUnlocked(QuestInstance.java:741)
	at betterquesting.questing.QuestInstance.update(QuestInstance.java:216)
	at betterquesting.handlers.EventHandler.onLivingUpdate(EventHandler.java:120)

Full log: https://gist.github.com/HenryLoenwind/dae2a7c95a337c01b2df4900c559bd46

Version: 3.5.269

Pack is Modern Skyblock 3.4.2, nothing updated but BetterQuesting.

I doubt it would run in a decompiled dev environment so don't worry about it. There's only so many places I can put debug lines when dealing with a programming race condition anyway but I'll see what I can do about making a debug build for this issue

I think this is the second time I've seen this crash. Never really figured out how exactly it ended up in that state considering multiple threads would need to be reading/writing to a specific quest.

Commands are server side, the networking packets forward through the main server thread too, and I can't see any other mods tampering with this data so I really am stumped.

Just a quick FYI: I went back to 3.5.253 and it doesn't crash. So you 'only' need to look at code that was changed in the last 6 months.

That's still a lot of code but I guess that narrows it down to the new backup service, save load events, update code and maybe some quest cache changes. I'll skim through those a bit of that today for any obvious things that stick out as a potential cause.

I think I've found a potential cause. It doesn't seem directly related to any of the new code but rather the server-client sync code running in single player leading to database writing on the client thread while still running the server thread ticks. Seems me simply moving events around made the already existing race condition line up just right to trigger crashes.

I'll see to adding a check for this and disable syncing for SSP or the LAN host.