This was found on 1.15.3, but reproduces on 1.14.x (27b01c1)

Example crash report attached.
crash-2020-04-17_22.16.23-server.txt

This seems to reliably trigger when used by a player, but can also trigger when a pedestal uses the item, but the pedestal is much less reproducible.

After digging around with the debugger, it looks like validateBigStackSlot is getting called with the "true" index of the slot, as opposed to its "filtered" index, This often is not grounds for a crash, because there are typically N+1 stacks, where N is the number of plantable, so these align, and if the rod runs out of a plantable, the remove happens on both the "true" and "filtered" stacks. However, as the zeroth stack is reserved for bonemeal, if it runs out, all the filtered stacks will shift one over, meaning that anything that indexed based on unfiltered indexes may be off, and if the last plantable is selected, this results in an out of bounds array access.

I'm not sure if getCurrentPlantableSlot is supposed to return the "inventory slot of the item that contains the target plantable" or "of the slots that contain plantables, the Nth one is selected"

My java-fu is apparently too weak to keep track of all these lambdas in here. so I'm unable to build a patch...

I //think// that assumption that plantable slots are always offset by one is here, but it may also be in other places.

If the bonemeal slot in fact gets removed that's the issue because that slot shouldn't be removable only plantable ones are supposed to remove when it runs out of the given plantable. I will take a look at that.

What's worth noting, is that the slot itself is not removed, it just stops matching the filter, so it doesn't make it into the filtered bigStacks

This is now fixed in a new release