Project

General

Profile

action #107632

[qe-core][leap][sporadic] Fix chromium test failing due to dropped keys

Added by apappas 6 months ago. Updated 3 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

The chromium test module fails sporadically because it is not resilient against dropped keys.

This particular failure happened because the enter_cmd "chrome://version" line typed chron instead of chrome::version

openQA test in scenario opensuse-15.3-DVD-Updates-x86_64-gnome@64bit-2G fails in
chromium

Acceptance Criteria

  • AC1: The test checks for incorrect input on the address bar using a needle that covers the expected input
  • AC2: The test retries to input the adresses correctly N times (click the address bar and retype, better than using eg Ctrl-L in case the system is busy)

Reproducible

Fails since (at least) Build 20220217-3

Expected result

Last good: 20220217-2 (or more recent)

Further details

Always latest result in this scenario: latest


Related issues

Related to openQA Tests - action #109737: [opensuse][sporadic] test fails in chromium due to lost characters when typing in the address bar size:MBlocked2022-04-09

History

#1 Updated by apappas 6 months ago

  • Subject changed from [qe-core] to [qe-core][leap][sporadic] Fix chromium test failing due to dropped keys
  • Description updated (diff)

#2 Updated by tjyrinki_suse 6 months ago

  • Status changed from New to Workable
  • Start date deleted (2022-02-25)

#3 Updated by tjyrinki_suse 5 months ago

  • Target version set to QE-Core: Ready

#4 Updated by tjyrinki_suse 5 months ago

  • Description updated (diff)
  • Parent task set to #102215

#5 Updated by zluo 5 months ago

  • Assignee set to zluo

take over and checking

#6 Updated by zluo 5 months ago

failed already at https://openqa.opensuse.org/tests/2235822#step/updates_packagekit_gpk/24
and
http://10.162.30.85/tests/4622#step/check_system_is_updated/12
I don't think this will work and stay stable for long time: 64bit-2G machine for such complete and updated installation, with testing of application like chromium.

#7 Updated by zluo 5 months ago

I checked this and found in Jobgroup of DVD-Updates:

x86_64:
    opensuse-15.3-DVD-Updates-x86_64:
    - textmode:
        machine: 64bit
    - gnome:
        machine: uefi
        settings:
          QEMUVGA: cirrus
    - gnome:
        machine: 64bit-2G
        settings:
          QEMUVGA: cirrus

Same tests but on different machines and this is clearly a performance issue . 64bit-2G is so instable and won't schedule such heavy installation/update tests on it. I can exclude chromium for a observation. If other test modules are also love to fail, then I can un-schedule it.

#8 Updated by zluo 5 months ago

https://openqa.opensuse.org/t2243182

try to verify this issue directly on O3 because my local openqa server has problem with installation (repo issue, network issue).

#9 Updated by zluo 5 months ago

  • Status changed from Workable to In Progress

#10 Updated by zluo 5 months ago

  • Status changed from In Progress to Rejected

https://openqa.opensuse.org/tests/2243321#next_previous no issue at all for chromium. 50 test runs, but there is other test module failed, vlc, oocalc.
So I would say, the performance issue of worker. but since I cannot reproduce this issue, there is no need to pay attention to it.
Set is for now as rejected. I can re-open it if chromium fails again.

#11 Updated by zluo 5 months ago

  • Status changed from Rejected to Blocked

Maybe this is related to an issue with call trace: https://bugzilla.opensuse.org/show_bug.cgi?id=1197122
So set is as blacked for now and wait feedback from developer.

#12 Updated by zluo 5 months ago

  • Status changed from Blocked to In Progress

it looks that the recent tests are okay again, let me keep this ticket for a while.

#13 Updated by zluo 5 months ago

according to my tests (more than 100 test runs), there is not a problem to chromium test module, but to performance of worker:

  • no issue with qemuram, but found evidence for network issue: 10.162.30.85/tests/4923#step/updates_packagekit_gpl/17 and
  • my assumption for poor cpu power, because there is no specific recording for cpu performance in logs, which cannot be determined at all.
  • call trace has been displayed from POST_FAIL_HOOKS, not the problem causes failure Normal successful test run on my slow machine takes about 1 hour 50 minutes. So I don't see an issue with MAX_JOB_TIME=14400

#14 Updated by okurz 5 months ago

zluo wrote:

according to my tests (more than 100 test runs), there is not a problem to chromium test module, but to performance of worker:

so what do you suggest to do about such "performance of worker"-problem?

#15 Updated by zluo 5 months ago

okurz I would suggest to rapidly reduce the number of workers of 64G-2GB machine. Single worker on my test machine works fine and can prevent this kind of issue.

#16 Updated by okurz 4 months ago

zluo wrote:

okurz I would suggest to rapidly reduce the number of workers of 64G-2GB machine. Single worker on my test machine works fine and can prevent this kind of issue.

which worker host are you talking about here please? Yes, likely personal workstations have lower load anyway, so production tests need to accomodate for that within the test design.

#17 Updated by okurz 4 months ago

  • Related to action #109737: [opensuse][sporadic] test fails in chromium due to lost characters when typing in the address bar size:M added

#18 Updated by szarate 4 months ago

  • Status changed from In Progress to Rejected

Rejecting in favor of #109737

#19 Updated by szarate 3 months ago

  • Sprint set to QE-Core: April Sprint (Apr 13 - May 11)

Also available in: Atom PDF