rework jsonrpc error handling

Issue #276 new
dd1 created an issue

As requested by bugs #209 and #261, RPC error handling needs to be reworked. I think we should do this:

  • RPC errors from user initiated actions (start run, etc) should yield an error dialog (up to the user to give up, try again, debug the error, try to fix the cause of error).
  • RPC errors from background activity (alarm page periodic load of alarm data) should not show a dialog. report the error somewhere on the page, shade the page “gray” (information out of date), retry the RPC, once the error is gone, restore the page to normal appearance.
  • “500 series” HTTP errors should be retried automatically. but we need to notify the user that something is not right. For us, “500 series” HTTP errors is usually “mhttpd is not running”, “apache proxy cannot connect to mhttpd”, etc, where we know mhttpd will come back sooner or later.
  • I am not sure if we should retry user-initiated RPCs. I think we should try to implement this, but if usability is bad we may have to rethink it. For example: “start run” → RPC error → automatic retries → page is stuck in a retry loop, user puts it in the background and forgets about it → 2 weeks later the RPC error clears, retry successfully completes, and a run is unexpectedly started.
  • RPC requests generated by history plots to load more data should not throw error dialogs (bug #261), hopefully automatic retry of “500 series” HTTP errors should be sufficient for this.

K.O.

Comments (2)

  1. Stefan Ritt

    I agree that some of the above cases should notify the user about a current issue, but then go away without the user having to press the “OK” button of a dialog box. I would propose to use the UI we use for broken RPC connection. Kill mhttpd and you will see a red stripe on top of the page with some info that the process tries to re-connect. It automatically goes away when the connection is established again.

    Maybe we can use the same scheme for some of the RPC errors.

    We can do this by simply calling mhttpd_error() in mhttpd.js

    I also should put there a

    mhttpd_error_clear() {
       document.getElementById("mheader_error").innerHTML = "";
       document.getElementById("mheader_error").style.zIndex = 0; // below header
    }
    

  2. Log in to comment