action #32611
closedcoordination #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
0%
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
Updated by okurz almost 7 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
Updated by EDiGiacinto almost 7 years ago
- Related to action #28018: [tools] Regression: Page refresh of a liveview displays no image added
Updated by okurz over 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"
Updated by okurz over 6 years ago
- Related to action #37405: The state of the task has been staying in:State: uploading added
Updated by okurz over 6 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 :)
Updated by okurz almost 6 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".
Updated by okurz over 4 years ago
- Related to action #25814: load job page, e.g. test details, only on demand added
Updated by okurz over 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"
Updated by mkittler over 4 years ago
For some reason I can not make #65402 the parent task right now (it always says the ID is invalid).
Updated by mkittler over 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.
Updated by mkittler over 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.
Updated by okurz over 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.
Updated by mkittler over 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.
Updated by mkittler over 4 years ago
PR for AC3: https://github.com/os-autoinst/openQA/pull/2988
Updated by mkittler over 4 years ago
- Status changed from Feedback to Resolved
- Target version deleted (
Current Sprint)
The last PR has been merged as well.