In my experience preconditions are invaluable but fine grained post conditions within a function can get unwieldy really fast. I tend to move my post conditions outside to the caller. So, they end up in my calling modules and integration tests which call the logic directly.
So, responsibility for determining the correctness of the return value and what to do next (return error, retry, ..etc). falls to the caller.
That sounds wrong to me because then you will have duplications of the postconditions after each call. I haven't experienced any unwieldiness of having them at the end of a function.
It is more along the lines of when do you have post conditions that make more sense without the calling context.
I write mostly small pure functions. In those with proper preconditions it is impossible to have invalid output since the output for a given set of inputs is always the same. So, if the inputs are valid then the output must be valid as well.
Where I can’t write pure functions the post conditions are more along the lines of evaluating status codes and/or response bodies. Those I have found make more sense to allow the caller to evaluate and choose what to do in the context of the calling action. It isn’t that I am duplicating post conditions but that it is really better handled with more context as to what is being done since different callers may have different definitions of a correct response.
It is entirely possible though that in different domains or languages that post conditions make more sense. I am not saying their bad by any means. It just in what I work in currently I tend to just turn those post conditions into preconditions for the next action or gating some recovery logic.
But, I have tended to prefer flat call structures and keep retries and error handling logic at the application/service entry points if possible.
So, responsibility for determining the correctness of the return value and what to do next (return error, retry, ..etc). falls to the caller.
Just wanted to throw that out there.