gsamokovarov
commented
8 years ago I do feel your frustration. It gets tricky, especially when you don't suspect WebConsole::Middleware or ActionPack::DebugExceptions were the ones failing, because as you saw, there is no backtrace and you are in the dark.
I'll try to describe how Web Console works, so I can elaborate on the positioning:
When a request comes in, WebConsole::Middleware checks if it has to evaluate code in an already saved bindings. We call this a session. Those requests are initiated by the console UI itself. In this case, the middleware evaluates the input code and halts the middleware chain with a JSON for the console UI.
If this is not the case the, the middleware will let the other middlewares do their job and after they're done, will listen to whether someone in there wanted to initiate a new Web Console session. If they did, we insert the console UI alongside the already rendered content.
A session can be initiated by the console helper, which you can use in controller or view context. It saves a binding in env['web_console.binding'], which we can pick up and create a new session for it.
A session can be initiated from an exception as well. For this case, we have monkey patched ActionPack::DebugExceptions to leave the exception it's handing in env['web_console.exception'].
This is why we position WebConsole::Middleware before ActionPack::DebugExceptions in the middleware stack. We let Debug Exceptions handle the error, display the page and return the flow back to us. Then we insert the console UI in the response and create a session with the exception bindings, so the UI can evaluate code in them. That's probably where things fail for you. That's my guess.
So how I debug it? It's kinda primitive, but I attach a debugger at the beginning of WebConsole::Middleware#call and walk through every expression, testing where the middleware is blowing up. The monkey patch of ActionPack::DebugExceptions can be the one failing as well... ActionPack::ShowExceptions is there in development as a last resort. If everything else fails (even if it is ActionPack::DebugExceptions or WebConsole::Middleware) display something for the users.
To help with that, we can log exceptions in WebConsole::Middleware#call and continue without the console in the request when they occur. While those errors won't be actionable, the exempt from the logs can be useful for bug reports. I don't think we need to duplicate any code from Debug Exceptions here and I'll try to work on that. I'm quite curious what caused this for you...
schneems
olivierlacan
sgrif
thiensubs
Hit a bug in web_console when trying to upgrade to Rails 5. It took me hours to figure out where it was coming from. This was the only thing in my logs:
This was what I was rendering in development mode:
Why was this happening? Web-console inserts itself right before
debug_exceptionsmiddleware which makes sense, normally this is the middleware that would render the error to the logs, however web-console relies on getting the request before this point. Unfortunately this means it comes right aftershow_exceptionsmiddleware which contrary to the name, does not show what exception is occurring, instead it swallows it and returns a default 500 response.Bug: Web-console doesn't have any kind of fail safe response or debugging when internals fail. Either let's find a way to play nice with debug-exceptions middleware and put it afterwards, or essentially duplicate logic in debug-exceptions so we at least log errors to the logger.