A few different users have reported a similar crash, a null exception on the currentAnimation inside the animation queue.

Full log from one user:
https://gist.github.com/baileyholl/a65732e0a6f07dea8008363de25f9274

crash log from a different user:
https://bytebin.lucko.me/BKkUAAV4NC

I have not been able to consistently reproduce this in dev, and for these users, it is also irreproducible. They can trigger the animation consistently several times, and then randomly crash. This is a shaded version of geckolib as well, if relevant.

relevant tile code: https://github.com/baileyholl/Ars-Nouveau/blob/1.20/src/main/java/com/hollingsworth/arsnouveau/common/block/tile/EnchantingApparatusTile.java

relevant renderer: https://github.com/baileyholl/Ars-Nouveau/blob/1.20/src/main/java/com/hollingsworth/arsnouveau/client/renderer/tile/EnchantingApparatusRenderer.java

Note: the git is further ahead in changes than when the users crashed. I added a catch around ArsGeoBlockRenderer#actuallyRender to save them in the meantime, other than that the geo renderer is just a translation fix to remove the 0.01Y offset the geckolib blocks have

This is the tile code at the time of the crash (pre diff): baileyholl/Ars-Nouveau@2466ddd#diff-cb26e38bed812b293b0838c178821d031678a71d299c072204ba437ffefcb9d5

Just speculation, I wonder if it is something with the way I was triggering the animations? These were being started via a packet. On latest ive just changed it to a boolean that flips on/off.

 @Override
    public void startAnimation(int arg) {
        try {
            if (craftController != null) {
                craftController.forceAnimationReset();
                craftController.setAnimation(RawAnimation.begin().thenPlay("enchanting"));
            }
        }catch (Exception e){
            e.printStackTrace();
        }
    }
    ```

Why not just use triggered animations?

Haven't looked into those yet since I am still porting, should that impact the nullability of animations though? I would have figured its safe to reset and set animations at any point, packet or entity data or whatnot

No, it bypasses it
The nullability thing is something I can look into in time

I've put in a fix for this in 1.20.1, but as you know it's tricky to replicate, so reopen this if it continues to happen after you update to 4.2.1+