Hi everyone! I am working with Enterprise Gateway and want to be able to propagate error messages (such as those raised from kernel creation timeouts) from Enterprise Gateway to the end user in Jupyter Lab. Currently, Jupyter Lab just shows a generic error message to the user like the following:
This message is very ambiguous and doesn’t tell the user what happened. I’d like to be able to tell the user exactly why their kernel creation failed (again, such as saying that the kernel creation timed out). Enterprise gateway is sending a payload back to Jupyter Server with the error message, but it never gets shown to the user. I was wondering what the best way is to change this behavior so that users can see a descriptive error message that is returned from Enterprise Gateway.
Looking through the jupyter_server code, I found where the error message is altered and changed to the basic one returned to the user: jupyter_server/gateway_client.py at d85874b0d6ad16c8797bb99425b0282dea33630b · jupyter-server/jupyter_server · GitHub. Would it be best practice to create a Jupyter Server extension to alter the behavior of this gateway_request function and monkey patch it throughout jupyter_server? Or would it be better to suggest a feature enhancement to jupyter_server and make a contribution to properly propagate error messages?
Thanks!
hi @broden-wanner - no need for a server extension. If gateway_client.py is masking a more contextual error, we should let the original flow and better-propagate errors. A contribution would be welcome! (Thank you)
You might find it necessary to alter EG as well.
cc: @lresende - as he and I were talking about this very topic a few hours ago. 
2 Likes
Sounds good @kevin-bates! I can get to work on a contribution! Out of curiosity, what changes do you think will need to be made to Enterprise Gateway if we propagate errors through Jupyter Server? Are you thinking we’d have to update the error messages sent or their structure?
1 Like
I can get to work on a contribution!
Awesome - thank you!
Are you thinking we’d have to update the error messages sent or their structure?
I’m just not sure if some changes in this area would be necessary. However, if you’re seeing the desired content make its way over to jupyter server and its clear how to access that content within gateway_client, then we’re probably good to go.
1 Like
One way would be to use content-type for backward compatibility and use some sort of richer error responses from the gateway side where more details could be provided to the front end.
1 Like
@kevin-bates and @lresende, thanks for the input! In my experience, I am seeing most of the error information I need in the JSON payload that is passed to Jupyter Server from Enterprise Gateway, but I would be open to enriching the error responses from the gateway side if you both know of any other information that should be included. If we want to alter the error messaging on the Enterprise Gateway side of things, should that be done before making any updates to Jupyter Server error propagation?
I also created an issue on the jupyter_server repo add error propagation if you want to continue our discussion there: Propagate Enterprise Gateway Error Messages to Frontend Users · Issue #1231 · jupyter-server/jupyter_server · GitHub.
I think we can treat these independently for now. We can circle back on this if necessary but let’s move forward with your contribution on the gateway client side of things. Thank you.
1 Like
