I try to abide by these three rules:
- Never allow a user to work with an application in an inconsistent state. This allows at the very least to unexpected behavior and probably to subtle (and not so subtle) bugs.
- Always try to handle errors automatically, without informing the user. The less cognitive hassle for the user, the more usable your app is. Of course there are errors that have to be notified to the user.
- Always try to inform the user as soon as possible of any relevant error that wasn't handled automatically. After the two above rules, inform as soon as possible so the user isn't kept wondering about what is happening, provide visual feedback constantly, if appropriate.
So, I'd have the application to fix its internal state, then inform the user, but only if it's really necessary (maybe implement a retry scheme, for example.)
EDIT: In the case where user means actually a client application, I think that rule 1 still applies. If you return to the client application before having your internal state consistent, the client application could send immediately a new request when your state is still inconsistent. So you could, either choose to do a check on every request to see if you are in an inconsistent state and raise a NotReady event, or just avoid that check and only return control to the client only when you are ready.