Project

General

Profile

Actions

action #32611

closed

coordination #34357: [epic] Improve openQA performance

coordination #65402: [epic] Revamp test details page to improve loading times and prevent timeouts

job details in browser windows do not automatically jump from "assigned" to "running" when they start - take 2

Added by okurz about 6 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Regressions/Crashes
Target version:
-
Start date:
2017-08-25
Due date:
% Done:

0%

Estimated time:

Description

as in #23648, still or again happening

Steps to reproduce

  • clone existing job in firefox
  • keep the tab open until the job starts
  • observe that the state is still "assigned" while screenshots are updated
  • observe the job is reported correctly as "running" after reloading the tab with "f5"

Acceptance criteria

  • AC1: The job state on the job details page refreshes when the job state changes
  • AC2: The content on the job details page refreshes until we reach a "finished" state
  • AC3: The complete web page is never refreshed, only relevant data

Suggestions

  • Research how we refresh page content during "Running"
  • Apply the same for other states
  • Ensure that "Uploading" does not hard-refresh the complete page in the browser
  • Ensure that jobs switch automatically from "Assigned" to "Running"

Workaround

Reload the browser tab.


Files


Related issues 4 (0 open4 closed)

Related to openQA Project - action #28018: [tools] Regression: Page refresh of a liveview displays no imageResolvedcoolo2017-11-21

Actions
Related to openQA Project - action #37405: The state of the task has been staying in:State: uploadingResolvedokurz2018-06-15

Actions
Related to openQA Project - action #25814: load job page, e.g. test details, only on demandResolvedmkittler2020-04-07

Actions
Copied from openQA Project - action #23648: job details in browser windows do not automatically jump from "assigned" to "running" when they start (regression: previously working was scheduled to running)Resolved2017-08-25

Actions
Actions #1

Updated by okurz about 6 years ago

  • Copied from action #23648: job details in browser windows do not automatically jump from "assigned" to "running" when they start (regression: previously working was scheduled to running) added
Actions #2

Updated by EDiGiacinto about 6 years ago

  • Related to action #28018: [tools] Regression: Page refresh of a liveview displays no image added
Actions #3

Updated by okurz about 6 years ago

  • Subject changed from job details in browser windows do not automatically jump from "assigned" to "running" when they start - take 2 to [tools]job details in browser windows do not automatically jump from "assigned" to "running" when they start - take 2
  • Status changed from Resolved to New

oops, I think I cloned the original ticket but did not update the status to "open"

Actions #4

Updated by okurz almost 6 years ago

  • Related to action #37405: The state of the task has been staying in:State: uploading added
Actions #5

Updated by okurz over 5 years ago

Still, happening, just now observed in https://openqa.opensuse.org/tests/735153 but of course going to that job will show it as "running" for you :)

Actions #6

Updated by okurz over 5 years ago

still happening, see attached screenshot as well. I triggered a job, it was "scheduled" as first, then jumped to "assigned" and was actually executing tests but never jumped to "running". However, in the end it jumped to "passed".

Actions #7

Updated by okurz about 4 years ago

  • Related to action #25814: load job page, e.g. test details, only on demand added
Actions #8

Updated by okurz about 4 years ago

  • Subject changed from [tools]job details in browser windows do not automatically jump from "assigned" to "running" when they start - take 2 to job details in browser windows do not automatically jump from "assigned" to "running" when they start - take 2
  • Description updated (diff)
  • Status changed from New to Workable

QA tools team discussed this 2020-04-07 and we have the following ideas:

  • What we already do in "running" can be applied in all other cases, e.g. only reload relevant parts, not reload whole page
  • Also see related #25814 about loading other content on demand
  • In general we want to have automatic refreshes of the page until we reached a "finished" state but only reload data and not the complete pages, e.g. as happens during "uploading"
Actions #9

Updated by mkittler about 4 years ago

For some reason I can not make #65402 the parent task right now (it always says the ID is invalid).

Actions #10

Updated by mkittler about 4 years ago

  • Status changed from Workable to In Progress
  • Assignee set to mkittler
  • Target version set to Current Sprint

I'd like to start with this ticket as first part of the overall epic ticket #65402 (which I still cannot set as parent). As a first step I'd like to unify the polling for status changes. So far we're using AJAX polling only while a job is running. That should be done in any state except done instead refreshing the whole page.

Actions #11

Updated by mkittler about 4 years ago

  • Parent task set to #65402
Actions #12

Updated by mkittler about 4 years ago

With https://github.com/os-autoinst/openQA/pull/2943 we should already be a step closer to AC3. AC1 and AC2 are already implemented.

Actions #13

Updated by okurz about 4 years ago

  • Status changed from In Progress to Feedback

async details loading is live on o3. And it's awesome 🙂

IMHO AC1-3 are all covered as the whole page never seems to refresh anymore anyway. All state transitions seems to be fine while monitoring a job from scheduled over assigned to running as well as finished jobs. I have not yet seen how change to/from uploading looks and feels but I am confident this will be all good now as well. Do you plan anything further? Keep in mind that this ticket is not for "load only parts of modules at a time" or something like that.

Actions #14

Updated by mkittler about 4 years ago

IMHO AC1-3 are all covered as the whole page never seems to refresh anymore anyway.

That is not true. It still refreshes on each state transition. As you've mentioned in a later comment yourself:

There is still a small step visible between "running" and "uploading" when the screenshots are rendered again even though previously they were all already visible.

(https://progress.opensuse.org/issues/65402#note-5)

Do you plan anything further?

I would avoid the full page reload on state transitions. It should not be that hard to enable/disable state-dependent tab headers via JavaScript and update the info panel. Since loading on demand is already implemented there shouldn't be that much other details to be sorted out.

Keep in mind that this ticket is not for "load only parts of modules at a time" or something like that.

I'd thought that this feature would belong to #25814 so see my comment there.

Actions #16

Updated by mkittler almost 4 years ago

  • Status changed from Feedback to Resolved
  • Target version deleted (Current Sprint)

The last PR has been merged as well.

Actions

Also available in: Atom PDF