action #36613

action #14818: [EPIC] Interactive mode is an usability disaster

action #36442: Access to running SUTs for System Developers

Implement WS connection from web UI to command server

Added by mkittler over 2 years ago. Updated over 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


  • AC1: Limit the use of the connection to one developer
    • Save the current developer and display it somewhere in the web UI
  • AC2: Allow to pause the execution at a certain test using the ws connection


#1 Updated by mkittler over 2 years ago

Ok, so let's say a user clicks on 'Start developer mode' in the live view to enable certain controls (eg. set the test to pause at, resume, ...). What should happen under the hood? Maybe the following:

web browser <=ws or AJAX=> web UI <=ws=> os-autoinst command server

  1. The JavaScript does an AJAX call or opens a ws connection to the web UI server.
  2. If the job isn't running, this results in an error. Otherwise:
  3. The web UI server creates a new entry in the table DeveloperSessions to keep track of what happens in the following steps.
    • The entry is identified by the job id and contains further meta-data like the user id and maybe further status information.
    • If the entry already exists, a specific error is returned and handled by the JavaScript.
    • I wouldn't add the additional information for the developer session directly to the jobs table because the columns wouldn't be used most of the time and the jobs table is quite big.
  4. The web UI server opens a websocket connection to the os-autoinst command server.
    • The connection is kept open as long as the developer session is open.
    • Likely the connection can just be initialized in the controller callback. Eg. my $cmd_srv_connection = $self->app->ua->websocket(...); Or do I have to take special care because the life-time of the ws connection will exceed the execution of the controller callback?
  5. The JavaScript client sends further commands, eg. to pause the test at some step.
  6. The web UI server validates and passes the command to the command server.
  7. At some point the test is actually paused which is noticed by the web UI server through a message from the command server.
  8. The developer mode is canceled or the test finishes.
    • The web UI server closes the web socket connection to os-autoinst and removes the entry in the DeveloperSessions table.

#2 Updated by mkittler over 2 years ago

The web socket connections browser <=> web UI <=> os-autoinst are basically working now.

developer console

WIP branch: (most relevant file so far:

So next step is to add the table mentioned in the previous comment.

#3 Updated by mkittler over 2 years ago

Current problems so far:

  • Test with multiple chromedriver instances to test behavior when multiple tabs open. In the first place I thought this works, but unfortunately this is not reliable and I haven't been able to change that it works.
  • Not sure how to write unit tests for the websocket routes. I'm still reading the documentation for this. But I already noticed that the way I'm using to send errors to the JavaScript client doesn't work well.

#4 Updated by mkittler over 2 years ago

  • Status changed from In Progress to Resolved

The mentioned problems should be solved and the PR is merged.

#5 Updated by szarate over 2 years ago

  • Target version changed from Current Sprint to Done

Also available in: Atom PDF