From a purely theoretical standpoint, (irrespective of the particular situation that you have at hand,) an event signifies a state transition of a system. Now, if an error occurs during the processing of a request, then ideally, the system should have a built-in rollback mechanism, so no state transition should occur, therefore, no event should be issued. If, nonetheless, a state transition does occur, then an event should of course be issued, but it should only contain information about the state transition. Error information does not fit into this picture; it is irrelevant. Observers of events expect to be notified about transitions so as to take appropriate action, they have no use and no interest in knowing anything whatsoever about errors.
Now, all that is completely unrelated to the response of a request. When a client sends a request, the server sends back a response to that client, and only to that one client. (Additionally, if the processing of the event results in a state change, then it will issue a state change event to all registered observers, but that's a different issue.) This response to the requesting client should, of course, contain error information in case of failure. The fact that you are using an event mechanism to implement your responses is completely irrelevant, and actually plays the role of a red herring in this discussion. So, including an actual exception object within a response seems perfectly legit to me. That's precisely the reason why exceptions were invented: to free us from having to use enums.