In Medieval Minecraft fabric 1.19.2, there has been going around a difficult-to-diagnosis crash with custom armors and extra slots from Cosmetic Armor. I have managed to create a minimal reproduction case which is:

• Cosmetic Armor
• Trinkets
• Any mod that calls getEquippedStack in ArmorFeatureRenderer (Geckolib as example)
• Any mod with custom armor (Bumblezone as example)
  

Put on bumblezone armor in all main armor slot. Put diamond boot in cosmetic armor boot slot and Geckolib will crash. Now the player will always crash whenever they open their inventory until they edit the game's data to remove their armor. Well, it seems Minecraft is the one crashing because of a null pointer exception in getEquippedStack when attempting to call EquipmentSlot.getType(). Like the slot itself is null.

Remapped stacktrace: https://paste.ee/p/7OquQ
Full log: https://paste.ee/p/hJtWT
Single player world where player crashes instantly when opening inventory. CrashingSinglePlayerWorld.zip
ArmorFeatureRenderer class file with mixins applied for debugging purposes: https://paste.ee/p/YJJIc

Immersive Armors seems to have a similar setup as Geckolib as Immersive Armors gets a similar crash as well if I swap it out for Geckolib: Luke100000/ImmersiveArmors#65

Cosmetic Armor also has an issue report but I heard that the dev for it is not as active anymore: apace100/cosmetic-armor#23

Main thing is I would like to know which mod has the source of the bug so a solution can be provided to the right mod. Issue report is made here to bring awareness to Trinkets in case it is something with Trinkets.

Forgot to mention, the crash requires two different kinds of armors. Typically all armor slots filled with modded armor and then cosmetic armor slots filled with a different type of armor. Some combinations of armors do not crash. Others do. When a combination is found, the game will always crash on the inventory screen until game data is edited to remove the armor from player. Happens with Twilight Forest armor and even Minecraft Dungeons Armor’s armor too. So the issue lies probably in the slots, Cosmetic Armor, or the multiple mods trying to do the same stuff that Geckolib is doing in this ArmorFeatureRenderer class

While I haven't tested this out, looking at the code involved I think I have a theory as to what's going on.

Both Immersive Armors and Geckolib are crashing due to a null value that wasn't properly initialized. Immersive Armors tries to initialize this in renderArmor's first STORE instruction:
https://github.com/Luke100000/ImmersiveArmors/blob/1.19.2/common/src/main/java/immersive_armors/mixin/MixinArmorFeatureRenderer.java#L38

Geckolib tries to initialize theirs at renderArmor's HEAD:
https://github.com/bernie-g/geckolib/blob/1.19/Fabric/src/main/java/software/bernie/geckolib3/mixins/fabric/MixinArmorFeatureRenderer.java#L56

And they both expect these to be non-null by the time renderArmorParts is called.

The issue arises because neither of these will get initialized when Cosmetic Armor's own mixin cancels the rest of the method (which is always a potential conflict because their mixin is the one at the beginning of the method as seen in your debugging class file):
https://github.com/apace100/cosmetic-armor/blob/1.19/src/main/java/io/github/apace100/cosmetic_armor/mixin/MixinCosmeticArmorVisibility.java#L53

The cancellation requirement would explain why certain armor combinations do/don't trigger the crash, as it requires both the presence of a cosmetic stack and that either item has a custom renderer.

Awesome thank you! I'll try and reach out to Geckolib and Immersive armors and any other mods to try and get them to use a higher priority mixin to grab the slots/armor since it seem Cosmetic Armors did a inject cancel high priority to try and bypass Fabric API's inject cancel. This spot is a mess of everyone injecting at head lol. Closing this as it isn't a Trinkets issue