Project

General

Profile

Actions
Copy link

action #102786

closed

Text results "unable to read" when showing result page during test execution, i.e. while an openQA test is running size:M

Added by dheidler about 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Low
Assignee:
mkittler
Category:
Regressions/Crashes
Target version:
Ready
Start date:
2021-11-22
Due date:
% Done:

0%

Estimated time:

Description

Motivation

Serial text results can have a content like Unable to read glibc_locale-7.txt.. This text is rendered directly in the little text preview boxes. "record_info" boxes show their title correctly but might miss content.

While this can be similar with image results, these are refreshed a few times on the client side using javascript, until a proper image is received.

There should be some measurement taken to ensure that all results are shown properly.
Maybe a solution could be found, that could eliminate the need of the image reload approach.

Screenshot_20211124_125544_openqa_showing_unable_to_read_text_results_in_job_details_before_refreshing_job_just_passed.png

Screenshot_20211124_130016_openqa_showing_unable_to_read_on_record_info_box_detail.png

Impact

Only webUI users looking at job detail pages while openQA jobs are running, only text results (not simple text boxes and not screenshots)

Reproducible

Not always reproducible, likely more probable on tests with many serial text result boxes, e.g. dheidler suggested https://openqa.suse.de/tests/latest?arch=aarch64&distri=sle&flavor=JeOS-for-RaspberryPi&machine=aarch64&test=jeos-main-RPi&version=15-SP4

okurz and dheidler could both reproduce the problem while having the job https://openqa.suse.de/tests/7734443# from this scenario opened in our browser (we used Firefox and Vivaldi/Chromium at the same time and reproduced it in both). As soon as the job changed from "running" to "passed" the job detail info box correctly showed the status and all steps showed up but the content was "Unable to read" for all thumbnail boxes in the "flask" module, both for "serial text results" as well as "record_info" boxes. Refreshing the page or opening the same job in another browser tab rendered all entries correctly, no error shown.

Acceptance criteria

  • AC1: Both image and text results are reproducibly shown in job details whenever they are available while the job is running

Suggestions

  • Find a way to reproduce the problem in our tests, e.g. upload text results and wait for the job to complete
  • Check existing JavaScript code for image polling (function reloadBrokenThumbnails()) and possibly do something similar for text results

Workaround

For the time being as a user refresh the page, e.g. "F5" key during or after test execution.

Out of scope

  • Actual missing results are not included here

Files

Download all files
Screenshot_20211124_130016_openqa_showing_unable_to_read_on_record_info_box_detail.png (17.3 KB) Screenshot_20211124_130016_openqa_showing_unable_to_read_on_record_info_box_detail.png okurz, 2021-11-24 12:02
Screenshot_20211124_125544_openqa_showing_unable_to_read_text_results_in_job_details_before_refreshing_job_just_passed.png (113 KB) Screenshot_20211124_125544_openqa_showing_unable_to_read_text_results_in_job_details_before_refreshing_job_just_passed.png okurz, 2021-11-24 12:02

Related issues 1 (1 open — 0 closed)

Related to openQA Project (public) - action #94531: OpenQA worker randomly skips uploading artefacts for whole test modulesNew2021-06-23

Actions
Actions
Copy link
 #1

Updated by okurz about 3 years ago

  • Category set to Support
  • Assignee set to okurz
  • Target version set to Ready

dheidler wrote:

Serial text results have a content like Unable to read glibc_locale-7.txt..
While this can be similar with image results, these are refreshed a few times on the client side using javascript, until a proper image is received.

so are you saying that refreshing the image multiple times always resolves this error or is this an error that you see reproducibly?

Actions
Copy link
 #2

Updated by dheidler about 3 years ago

The root cause of results not being ready on the server when a test module finishes is very common.
I honestly don't know what it takes so long for - for pngs maybe the optipng is very slow but I don't know about the text results.

Anyway this refresh code (that was originally written by me) appends the unix timestamp to the image url to prevent caching and stores a counter in the dom object to count retries. It retries about three times IIRC with exdending intervals.
When the image has a width > 0px, it is considered successful and stops the retries.

This solves the problem for the broken images I guess nearly all the time but obviously there could be timeouts.

Anyway this is not done for text results a the moment.

Actions
Copy link
 #3

Updated by okurz about 3 years ago

  • Description updated (diff)

Sorry, I still don't fully understand what's the impact. Except for maybe something being slow or inefficient, how are users affected? Are there jobs that reproducibly don't render text results at all? If yes, can you reference such jobs by URL from o3 (or osd)?

Actions
Copy link Download all files
 #4

Updated by okurz about 3 years ago

Actions
Copy link
 #5

Updated by okurz about 3 years ago

  • Related to action #94531: OpenQA worker randomly skips uploading artefacts for whole test modules added
Actions
Copy link
 #6

Updated by okurz about 3 years ago

  • Category changed from Support to Regressions/Crashes
  • Status changed from New to Blocked

For now I will keep this ticket in "Blocked" by #94531 within our backlog. You might be onto something here which could help us for the same problem.

Actions
Copy link
 #7

Updated by mkittler about 3 years ago

  • Status changed from Blocked to New

Users are affected in the sense that they see "unable to read" for text results when while live-watching the test execution. Refreshing with F5 loads the text results. I assume we need a similar hack than for the images (see #102786#note-2).

So this is not the same as #94531 where the text results are missing permanently. This is only about text results missing temporarily because the upload is simply still ongoing and that they're not automatically reloaded. Hence this ticket is also not blocked by #94531.

Actions
Copy link
 #8

Updated by asmorodskyi about 3 years ago

I experienced same bug and I want to clarify a bit Impact : so I opened job which was running and keep it open till the end of the job . than I reviewed *already finished job * and I had same experience as described in this ticket . So it is affecting not only people who trying to watch running job but also one's who watching already done but had bad luck to open it while it was running .

Workaround :

  1. wait until job will be done .
  2. close tab and open it again
Actions
Copy link
 #9

Updated by livdywan about 3 years ago

  • Subject changed from Text results "unable to read" when showing result page during test execution, i.e. while an openQA test is running to Text results "unable to read" when showing result page during test execution, i.e. while an openQA test is running size:M
  • Description updated (diff)
  • Status changed from New to Workable
Actions
Copy link
 #10

Updated by okurz about 3 years ago

  • Assignee deleted (okurz)

was tracking only the "Blocked" state. Now with this ticket being "Workable", back to the backlog

Actions
Copy link
 #11

Updated by mkittler almost 3 years ago

  • Assignee set to mkittler
Actions
Copy link
 #12

Updated by mkittler almost 3 years ago

  • Status changed from Workable to In Progress
Actions
Copy link
 #13

Updated by mkittler almost 3 years ago

  • Status changed from In Progress to Feedback

The PR has been merged and I've also tested it locally with a few real test runs. Let's see whether it works in production. Note that with my fix one still gets "Unable to read…" but once the results have been uploaded they should be shown automatically (without having to reload the page). Not sure whether it makes sense to show some loading indication instead as we really cannot easily distinguish missing files from pending ones. (We could always show the loading indication as long as the job is still executed and when it enters a final state we'd consider the files missing. That's not perfect but would be a way to distinguish it if we wanted.)

Actions
Copy link
 #14

Updated by mkittler almost 3 years ago

  • Status changed from Feedback to Resolved

I suppose it is good enough.

Actions
Copy link

Also available in: Atom PDF