Bug 1219403

This test was newly added, so it is not clear how long it was failing already.

[2024-01-30T23:18:43.225032+01:00] [debug] [pid:6886] Sending action to widget by url: http://localhost:39113/v1/widgets?action=check&id=addon_repos&value=Desktop+Applications+Module

No y2logs here or at the test's "Logs and Assets" tab, and it's also completely missing a test description. :-((

Created attachment 872344 [details]
Screenshot with (cut off) error message

For future bug reports, please attach this to the bug since the life time of those openQA tests is so limited: They tend to get deleted before the problem can be addressed.

Let's see how far that cut-off error message can get us.

Not really helpful:

https://github.com/yast/yast-yast2/blob/SLE-15-SP3/library/general/src/lib/ui/event_dispatcher.rb#L51

So somebody sent a widget event with an ID that did not find a handler. That ID was 

  ./Module-Desktop-Applications

https://openqa.suse.de/tests/13379459/modules/select_module_desktop/steps/1/src

sub run {
    $testapi::distri->get_module_selection()->select_module('desktop');
}

...which obviously translated to that "./Module-Desktop-Applications" which was probably meant to be the item ID of that add-on module.

Including "./" in that ID sounds very wrong. My guess is that it's really "Module-Desktop-Applications".

Maybe that is one thing that changed from a previous version to the one being tested here, and some openQA library ("$testapi::") translates the desired module name to that, based on the distro / SP version which might now be wrong.

But that's only a wild guess.

I tried to check exactly which dialog that might be, and how the item IDs are structured, but there are multiple candidates.

So we'll really need y2logs (generated with the supplied save_y2logs script) for this; in this case with Y2DEBUG=1 on the media kernel command line.


It's still most likely that it's a problem on the OpenQA side - see comment #7.

ok, that's a first. Indeed Stefan is right. The test suite is using the libyui-rest-api. It checks if the extension and modules selection page is there and then proceeds to select Desktop applications module without making a second validation if the particular module selection is available as well. So I would assume that the request is just too fast and even though the page ID is present, not all items are loaded.

Let's close this bug. We will adjust the test. Sorry for the noise.