Shinoyuki-BetterAutoSave

v0.20.1 — Fixes a startup crash when installed alongside Lithium-family optimisation mods

0.20.0 crashes the server at startup when installed together with Harium, Radium, Radium Re-Reforged, Canary or another Lithium port. If you run any of those, upgrade to 0.20.1 or roll back to 0.19.0. Only 0.20.0 is affected

1. Symptom

Mixin application fails at startup and the entire config is rejected:

Mixin apply failed shinoyuki_betterautosave.mixins.json:ServerChunkCacheSyncLoadMixin
  -> net.minecraft.server.level.ServerChunkCache
InvalidInjectionException: @At("INVOKE") on ...betterautosave$measureSyncChunkLoad with priority 1000
  cannot inject into ServerChunkCache::m_7587_ merged by
  me.jellysquid.mods.lithium.mixin.world.chunk_access.ServerChunkManagerMixin with priority 1000

What fails is the sync-load detector added in 0.20.0, but the whole of shinoyuki_betterautosave.mixins.json goes down with it — async saving and async loading stop working too, and the server does not start

2. Cause

The 0.20.0 detector wraps the "wait until the chunk is ready" call inside ServerChunkCache.getChunk with @WrapOperation and declares require = 0, intending "if the injection point is gone, skip silently rather than let a pure observation feature take the server down"

That declaration does not cover the failure mode that actually occurred. Lithium ports @Overwrite getChunk outright, and Mixin has an earlier check in Injector.findTargetNodes: if the injector's priority is not higher than that of the mixin which already merged the method, it throws InvalidInjectionException immediately. Both sides sit at the default priority of 1000, so the condition fails — and because this check runs before the require hit-count check, require = 0 is never consulted

The 0.20.0 release notes said "the detector silently does nothing rather than failing server startup". The intent was right; the implementation did not deliver it. This release does

3. Fix

The detector's injection now passes a gate at class-load time. If either condition holds, the mixin is not applied at all:

1. diagnostics.syncLoadDetection is false in the on-disk common.toml (a missing file, section or key defaults to true)
2. A mod known to @Overwrite getChunk is present: harium, radium, canary, lithium

When the gate closes, a WARN line names the mod responsible:

[BetterAutoSave] sync chunk load detector disabled: mod 'harium' overwrites
ServerChunkCache.getChunk, which Mixin will not let us wrap. Async saving and loading are unaffected

That line is necessary: without it, "I installed 0.20 but never see any sync-load reports" has no explanation. Saving, async loading and every other feature are unaffected by this gate

Raising the mixin's priority was considered and rejected. BAS would then apply first, and the other mod's @Overwrite would replace the whole method body along with the injection — moving the crash risk onto them while this feature stops working anyway

4. Similar mods not on the list

Condition 2 is a whitelist covering the four known cases. If a mod that also @Overwrites getChunk appears and is not listed, set diagnostics.syncLoadDetection to false and restart (condition 1); no version update is required

The gating logic is identical on both loaders. The NeoForge side had no mixin config plugin before this release; one has been added

5. Verification

• 529 unit tests, 11 of them covering the gate itself: whitelist matching, case handling, a reverse assertion against false positives, TOML section awareness and default-value semantics
• Both directions verified on a 1.20.1 test server: BAS 0.20.0 + Harium 2.0 reproduces the startup crash reliably; with 0.20.1 the server starts normally and the log names harium; with Harium removed the server starts normally, the WARN is absent and the detector is injected as usual
• The crash exception is quoted verbatim in the source comments alongside the fix, so that require = 0 is not reached for again against this class of problem

6. Upgrading

Drop in the new jar. Save format and config keys are unchanged. Versions 0.19.0 and earlier do not contain this mixin and are not affected