Text results "unable to read" when showing result page during test execution, i.e. while an openQA test is running size:M
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.
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.
Only webUI users looking at job detail pages while openQA jobs are running, only text results (not simple text boxes and not screenshots)
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.
- AC1: Both image and text results are reproducibly shown in job details whenever they are available while the job is running
- Find a way to reproduce the problem in our tests, e.g. upload text results and wait for the job to complete
reloadBrokenThumbnails()) and possibly do something similar for text results
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
- Category set to Support
- Assignee set to okurz
- Target version set to Ready
Serial text results have a content like
Unable to read glibc_locale-7.txt..
so are you saying that refreshing the image multiple times always resolves this error or is this an error that you see reproducibly?
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.
- 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)?
- 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
#7 Updated by mkittler about 2 months 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.
#8 Updated by asmorodskyi about 2 months 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 .
- wait until job will be done .
- close tab and open it again
#9 Updated by cdywan about 2 months 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
- 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.)