action #134840
Updated by okurz 29 days ago
## Motivation
If an openQA worker picked up a job but is busy in early stages, in particular asset caching, the job details might show an empty live view and empty live log with no good feedback what is going on, see screenshot
The user of the webUI can not see what the worker is doing and shows a lot of disturbing empty screen estate. The user experience can be improved by better reflecting that the job is still busy in early setup, potentially what it is currently doing and also not show big empty boxes. On the worker one can see that the job is already busy based on content in worker-log.txt and autoinst-log.txt
Errors can be seen in the developer console:
```
Establishing ws connection to wss://openqa.opensuse.org/liveviewhandler/tests/4570289/developer/ws-proxy/status
test_result.js:332 Received message via ws proxy: {"data":{"category":"cmdsrv-connection","reason":"URL to command server unknown"},"type":"error","what":"os-autoinst command server not available, job is likely not running"}
test_result.js:340 ignoring error from ws proxy: os-autoinst command server not available, job is likely not running
test_result.js:326 Connection to livehandler lost
```
## Acceptance criteria
* **AC1:** The user of the webUI has a possibility to see the current state of the job in early stages, e.g. busy indicator as on index page, etc.
* **AC2:** No big blank frame with no content for a reasonable time
* **AC3:** The live view still shows up content as soon as the underlying SUT sends content, e.g. early bootloader frames
## Suggestions
* Look into the errors reported by the websocket handler. Maybe there is a race condition here?
* Potentially this is also a regression
* Avoid showing a blank space where the image will be
* Do not show the image unless an actual image from the SUT is available
* Overlay a spinner that is hidden once an image is available
* Consider a manual test setup to reproduce that (one without and with)
Back