Re-posting this as a separate issue since it seems to have been forgotten (ref).
This may or may not now be causing https://github.com/Johni0702/BetterPortals/issues/395 (might be a mod re-submitting tasks in its handler or a broken ArrayDeque due to thread-unsafe access. at least in quark there doesn't appear to be the former).
This seems more like a workaround than a fix.
Why is the Runnable null in the first place? Is that expected behavior?
It looks like to me that passing null to addAction can never serve any purpose. So having addAction throw a NPE and then fixing the caller sounds like a better solution.
Actually, upon looking at Quark, I realized that this isn't ever getting called with null (might still want to add the check for good measure) but instead it's getting called from other threads and pendingActions is an ArrayDeque which isn't thread-safe.
So this is definitely not the right way to fix it.
While on the topic:
Why does this even exist in the first place? I.e. why not just use Minecraft.addScheduledTask?
As is this will additionally cause compatibility issues with BetterPortals because BP hooks Minecraft.addScheduledTask to determine which world a particular runnable belongs to and will then make sure it's run in that context. It doesn't hook the pendingActions list so everything will just be ran in the main world.
Re-posting this as a separate issue since it seems to have been forgotten (ref). This may or may not now be causing https://github.com/Johni0702/BetterPortals/issues/395 (might be a mod re-submitting tasks in its handler or a broken
ArrayDeque
due to thread-unsafe access. at least in quark there doesn't appear to be the former).wrt https://github.com/Vazkii/AutoRegLib/commit/34d20805a2819843d8f6edeb71209b1dd2f9a07b: