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.
