Open tresf opened 6 years ago
What about taking advantage of our stream system for this?
Something along the lines of
qz.api.setExceptionCallbacks(function(event) {
console.log(event.exception);
console.log(event.message);
console.log(event.stacktrace);
// other things ?
}));
We'd have to go through and add a sendStream
java-side to all the exceptions we want visibility on, and make sure all sessions get a copy, but it should be possible.
What if we made it promise-driven fetch of the details only when one occurs? The exceptions are already being raised we just need more details.
Perhaps another option is to provide an API for fetching the logs?
I guess any solution may suffer the possibility of the exception being a breaking one and ending the WebSocket communication.
The problem with a fetch is we either have to have a queue to fetch from or you run the risk of having the exception you actually want to see being overridden by another and being unable to retrieve it without constant polling. Just having an api for fetching the logs instead might be the best compromise though.
If its a crash causing exception though, won't they have to remote in anyway to restart it? Probably not a situation we can respond to anyways, so not one we should worry about for now.
Yeah, that sounds like a good compromise.
For cloud providers, it is requested that we can provide a full
java.lang.Exception
backtrace from Java to JavaScript when an exception occurs to reduce the number of times the provider has to remote into the client workstation.This is a placeholder to track the feasibility of this request.