PlayerItemConsumeEvent is fired when it shouldn't be

[partydev]

What behaviour is expected:

Setting the food level of a player to 20 will not fire the PlayerItemConsumeEvent.

What behaviour is observed:

Setting the food level of a player to 20 fires the PlayerItemConsumeEvent.

Steps/models to reproduce:

    @EventHandler
    fun PlayerItemConsumeEvent.onConsume() {
        isCancelled = true
        player.setFoodLevel(20)
    }

Will continue firing the event. If you make a food item and cancel the consume event and then set the player food level to 20, it will keep firing the event in an infinite loop until they switch items.

Plugin list:

N/A

Paper version:

[16:04:34 INFO]: This server is running Purpur version git-Purpur-"54fdd69" (MC: 1.16.3) (Implementing API version 1.16.3-R0.1-SNAPSHOT)
[16:04:34 INFO]: Previous version: git-Purpur-786 (MC: 1.16.3)
[16:04:34 INFO]: Unknown version
(a fork of purpur that only modified being able to toggle lag compensating eating for testing)

Anything else:

N/A

[webcrawls]

Reproduce this on Paper

[aikar]

Works as intended. This event isnt even just limited to food at an abstract level.
This represents when the client is requesting to consume the active slot. it doesn't know if the action of the consumption is going to fail or not.

You likely want a PostConsumeEvent or something.

[YouHaveTrouble]

Excuse me, but WHAT. How is an API firing an event working as intended?

[chickeneer]

Excuse me, but WHAT. How is an API firing an event working as intended?

The original issue was not reported correctly. There is an issue - but the API is not firing the event as suggested here.

The actual bug here. Is that both cancelling the event and setting the player's food level is failing to unset the "raised hand" status and active item for that player. Which causes the server tick to repeatedly attempt to consume the item despite it being cancelled.
Adding some debug to the steps to reproduce will show that each event call is occurring during different ticks for the before mentioned reason.

A solution to work with the current broken mechanics - is to simply schedule the setFoodLevel AFTER the event is done. Best done by scheduling the action to run on the next server tick. I have confirmed that this solution does indeed prevent the event from repeatedly firing.

[chickeneer]

I suspect the solution is to add this.clearActiveItem(); to isCancelled part of the the event call for PlayerItemConsumeEvent in EntityLiving (but have not tested this solution)

[aikar]

doh, I misunderstood what the report was. I interpreted it as "The events firing even though my food was 20". Sorry about that.