You may need a few more words than that. My preferred definition of idempotency is that your actions take you to a desired state - if it didn't work, try again, and hopefully you'll get to the desired state this time.
The only time I've encountered an idempotency implementation in the wild, the team used the other interpretation of it, that is: the system will always respond the same for the same input. So if you try something and get an exception, they went through great lengths to ensure you would also get an exception the second time as well.
Your definition is generally inline with mine. The small exception is you can retry as many times as you can, once the desired state is reached, the result is the same after that no matter how many times you keep trying.
Using the example given, I (as producer) can retry the message however many times, the response I get should be the same. Implementation detail usually involves some kind of ID so downstream consumers know that they have process the said ID.
I do not believe if there is an exception, then future retry produce exception as well. But perhaps I misread your example.
The entire point of idempotency is not to always respond the same every single time, it's that the user can always expect the same response every single time. If the user receives a response it does not expect (or no response, etc.) than they don't want the same response on every retry, they still want the expected response
In a perfect world, an idempotent app responds the same every time. But in a perfect world you don't really need idempotency.
