I can easily believe it. This is related to the "when we detect you were too full to eat, we fail to roll back your fullness" bug. This would be a "when we detect that eating failed for any other reason, we fail to roll back your fullness."
The real issue is that we increment fullness when you submit the URL to eat and have to undo it later. That's not current "best practice" for how we handle requests to KoL. Here's a brief technical discussion.
Each kind of request can be submitted in two ways: from the GUI or CLI (i.e., under KoLmafia's control) or from the Relay Browser or visit_url (i.e., direct user action with KoLmafia not knowing exactly what is happening).
Each kind of request has a registerRequest method which examines the URL and writes to the session log.
Each kind of request SHOULD have a processResults method (which is called for KoLmafia-submitted requests), which calls some sort of "parse" method with the URL and response text. The "parse" method is also called StaticEntity.externalUpdate to handle Relay Browser and visit_url submitted requests.
The registerRequest SHOULD do nothing but logging, and the "parse" method is the place to check for success in the response text and, based on the URL, update KoLmafia's internal data model if the request was successful - and leave it untouched if the request failed. Given that, there would be no need to "roll back fullness" or other aspects of the data model.
Unfortunately, UseItemRequest updates fullness - and various preferences and such - in registerRequest, NOT in the "parse" method. LOTS of request classes used to operate that way, and I spent many many hours rewriting them to operate according to what I described above. Unfortunately, UseItemRequest is very complicated, since there are many kinds of items which can be used and there are many ways in which using can succeed or fail.
In summary: the best fix for this would be to move fullness updating into UseItemRequest.parseConsumption and only do it if eating succeeded. Ditto for inebriety and spleen.
I don't have time. Perhaps somebody else will tackle it - or, at least, will "roll back" fullness if we detect the "you can't eat that" message, whatever it is.