Direct answer

Folia’s public RegionScheduler schedules work for a world location. The internal RegionizedTaskQueue described in the Folia architecture solves a related ownership problem, but plugin authors should use the supported public API rather than reaching into server internals.

How to check it

  1. Locate the actual target world and block position; identify the code path that edits or reads it.
  2. Review plugin stack traces for cross-region access or wrong-thread errors. If a task accesses an entity that can move, it needs the EntityScheduler instead.
  3. Check that scheduled operations do not assume a permanently fixed owner: regions can merge and split as chunks are loaded.

What to change

Use the location-based API to run block changes on the correct region. This illustrative Java excerpt uses a plugin instance and a Location resolved earlier:

RegionScheduler scheduler = server.getRegionScheduler();
scheduler.execute(plugin, locationToChange, () -> {
    locationToChange.getBlock().setType(Material.BEEHIVE);
});

Do not synchronously wait for another region’s task while holding a region thread; restructure operations as callbacks or separate stages.

Compatibility and safety

The sample is for plugin developers targeting current Paper/Folia scheduler APIs, not a console command or a replacement for regular Paper configuration.

Software and version notes

These are Folia architectural and API concepts; test against the exact Folia and Paper API build you deploy. Do not apply generic Paper single-thread assumptions.

Verify the result

Test the action both when players are nearby and when chunks load/unload; confirm no thread-check exceptions and that only the intended block changed.

References