action #102786
closedText results "unable to read" when showing result page during test execution, i.e. while an openQA test is running size:M
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.
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
Updated by okurz over 2 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?
Updated by dheidler over 2 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.
Updated by okurz over 2 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)?
Updated by okurz over 2 years ago
- File Screenshot_20211124_125544_openqa_showing_unable_to_read_text_results_in_job_details_before_refreshing_job_just_passed.png Screenshot_20211124_125544_openqa_showing_unable_to_read_text_results_in_job_details_before_refreshing_job_just_passed.png added
- File Screenshot_20211124_130016_openqa_showing_unable_to_read_on_record_info_box_detail.png Screenshot_20211124_130016_openqa_showing_unable_to_read_on_record_info_box_detail.png added
- Subject changed from Text results "unable to read" when showing result page during text execution to Text results "unable to read" when showing result page during test execution, i.e. while an openQA test is running
- Description updated (diff)
- Priority changed from Normal to Low
Updated by okurz over 2 years ago
- Related to action #94531: OpenQA worker randomly skips uploading artefacts for whole test modules added
Updated by okurz over 2 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.
Updated by mkittler over 2 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.
Updated by asmorodskyi over 2 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 :
- wait until job will be done .
- close tab and open it again
Updated by livdywan over 2 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
Updated by okurz over 2 years ago
- Assignee deleted (
okurz)
was tracking only the "Blocked" state. Now with this ticket being "Workable", back to the backlog
Updated by mkittler over 2 years ago
- Status changed from Workable to In Progress
Updated by mkittler over 2 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.)
Updated by mkittler over 2 years ago
- Status changed from Feedback to Resolved
I suppose it is good enough.