Started by an SCM change3430d7e08f00bfff4790a205caf1d14eb36286c24c80d7e08f00bfff4790a205caf1d14eb36286c24c8refs/remotes/origin/master0d7e08f00bfff4790a205caf1d14eb36286c24c80d7e08f00bfff4790a205caf1d14eb36286c24c8refs/remotes/origin/master0d7e08f00bfff4790a205caf1d14eb36286c24c80d7e08f00bfff4790a205caf1d14eb36286c24c8refs/remotes/origin/masterhttps://github.com/mcMMO-Dev/mcMMO.gitfalse#34350574135282mcMMO #343343falsefalse343216FAILURE1783741749806https://popicraft.net/jenkins/job/mcMMO/343/Buildersrc/test/java/com/gmail/nossr50/TestRegistryBootstrap.java0d7e08f00bfff4790a205caf1d14eb36286c24c81783741267000https://popicraft.net/jenkins/user/nossr50nossr50nossr50@gmail.comFix registry bootstrap stubbing failing under CI test ordering The per-type registry mock minted its lookups through a when() stub registered inside the Bukkit.getRegistry interception, which runs in the middle of Registry class initialization. Mockito stubbing state is thread-local and unreliable while an intercepted invocation is being answered: on the CI runner the stub silently failed to bind, lookups returned null, and PotionEffectType class init failed with "No PotionEffectType found for minecraft:speed", poisoning the class for the JVM and erroring 108 tests. Locally a different test order made another class perform the first bootstrap, where the nested stubbing happened to bind. The minting now lives in the mock's default answer, baked in at creation with no stubbing machinery involved, and also covers getOrThrow for newer API versions. Explicit per-key when() stubs from test bodies still override the default answer. 2026-07-10 20:41:07 -07000d7e08f00bfff4790a205caf1d14eb36286c24c8Fix registry bootstrap stubbing failing under CI test orderingeditsrc/test/java/com/gmail/nossr50/TestRegistryBootstrap.javagithttps://popicraft.net/jenkins/user/nossr50nossr50