Don't assume history requests succeed in qtconsole #745

merged 3 commits into from Sep 9, 2011


None yet

2 participants

minrk commented Aug 29, 2011

If there was an error in user startup code, the history request will be aborted. It is generally not acceptable in frontends to assume that requests succeed. This assumption is made all over our frontend code, and should be be fixed. For now, this handles a known issue of the qtconsole crashing hard when invalid input is given to startup code (e.g. ipython qtconsole -c "DNE").

If the history request was aborted (this means a different request raised an error, causing the queue to be flushed), it will be tried again, exactly once, after waiting for the abort flush.

minrk added some commits Aug 3, 2011
@minrk minrk make ConsoleWidget LoggingConfigurable
This adds the attribute Widget.log, which is hooked up to the
running application's logger.
@minrk minrk Don't assume history request succeeded
errors in startup can cause the history request to be aborted.  There could be any of
a number of reasons the history request should fail, and the frontend should *never*
assume that the status is 'ok'.
@minrk minrk retry aborted history requests in qtconsole fc67794

Thanks for the fix, Min. I noticed this crash recently myself.

That said, this approach makes me a little leery. The Qt console (and no doubt other frontends as well) makes many different requests: for execution, history, tab completion, object info, etc. It seems painful to have check status and possibly retry the request under all these differences circumstances. I wonder if it possible to abstract at least some of this away, e.g. by having BaseFrontendMixin handle the retries automatically.

This is all somewhat vague. I will think about this some more and see if I can produce anything more substantial.


OK, I have an implementation plan for more robust error handling. Since this will involve some refactoring, I think it's worth merging this now as an interim fix.

@minrk minrk merged commit 17494a1 into ipython:master Sep 9, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment