Description
The plugin declares folia-supported: true in plugin.yml, but the migration subsystem calls the legacy global BukkitScheduler API, which does not exist on Folia. On a Folia server, Bukkit.getServer().getScheduler() throws UnsupportedOperationException, so the affected code paths crash.
Verified against the 4.2.0 jar. Both classes below call the legacy scheduler directly instead of the plugin's own Folia-safe abstraction (EssScheduler), which is used correctly elsewhere in the core:
EssMigrator
org.bukkit.Server.getScheduler()
BukkitScheduler.runTask(Plugin, Runnable)
MigrationCommand
org.bukkit.Server.getScheduler()
BukkitScheduler.runTask(Plugin, Runnable)
BukkitScheduler.runTaskTimer(Plugin, Consumer, long, long)
BukkitTask.cancel()
On Folia the global BukkitScheduler was removed; scheduling must go through GlobalRegionScheduler / RegionScheduler / EntityScheduler / AsyncScheduler. Because the core already wraps this in EssScheduler, the migration code is simply bypassing the existing abstraction.
Impact: any user who runs the migration flow on Folia will hit UnsupportedOperationException. More broadly, folia-supported: true is currently only partially true.
Steps to Reproduce
1.Run the server on Folia.
2.Trigger the migration command / migration flow.
3.Observe UnsupportedOperationException from Bukkit.getScheduler().
Expected Behavior
On Folia, migration scheduling should run through the existing EssScheduler abstraction (or the appropriate Folia region/async scheduler) instead of the global BukkitScheduler, so the advertised folia-supported: true holds for all code paths.
Version
4.2.0
Environment
None
Description
The plugin declares folia-supported: true in plugin.yml, but the migration subsystem calls the legacy global BukkitScheduler API, which does not exist on Folia. On a Folia server, Bukkit.getServer().getScheduler() throws UnsupportedOperationException, so the affected code paths crash.
Verified against the 4.2.0 jar. Both classes below call the legacy scheduler directly instead of the plugin's own Folia-safe abstraction (EssScheduler), which is used correctly elsewhere in the core:
EssMigrator
org.bukkit.Server.getScheduler()
BukkitScheduler.runTask(Plugin, Runnable)
MigrationCommand
org.bukkit.Server.getScheduler()
BukkitScheduler.runTask(Plugin, Runnable)
BukkitScheduler.runTaskTimer(Plugin, Consumer, long, long)
BukkitTask.cancel()
On Folia the global BukkitScheduler was removed; scheduling must go through GlobalRegionScheduler / RegionScheduler / EntityScheduler / AsyncScheduler. Because the core already wraps this in EssScheduler, the migration code is simply bypassing the existing abstraction.
Impact: any user who runs the migration flow on Folia will hit UnsupportedOperationException. More broadly, folia-supported: true is currently only partially true.
Steps to Reproduce
1.Run the server on Folia.
2.Trigger the migration command / migration flow.
3.Observe UnsupportedOperationException from Bukkit.getScheduler().
Expected Behavior
On Folia, migration scheduling should run through the existing EssScheduler abstraction (or the appropriate Folia region/async scheduler) instead of the global BukkitScheduler, so the advertised folia-supported: true holds for all code paths.
Version
4.2.0
Environment
None