Project

General

Profile

Actions

action #107632

closed

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

Added by apappas over 2 years ago. Updated over 2 years ago.

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

0%

Estimated time:
Difficulty:
Sprint:
QE-Core: April Sprint (Apr 13 - May 11)

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 1 (0 open1 closed)

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

Actions
Actions #1

Updated by apappas over 2 years ago

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

Updated by tjyrinki_suse over 2 years ago

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

Updated by tjyrinki_suse over 2 years ago

  • Target version set to QE-Core: Ready
Actions #4

Updated by tjyrinki_suse over 2 years ago

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

Updated by zluo over 2 years ago

  • Assignee set to zluo

take over and checking

Actions #6

Updated by zluo over 2 years 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.

Actions #7

Updated by zluo over 2 years 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.

Actions #8

Updated by zluo over 2 years 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).

Actions #9

Updated by zluo over 2 years ago

  • Status changed from Workable to In Progress
Actions #10

Updated by zluo over 2 years 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.

Actions #11

Updated by zluo over 2 years 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.

Actions #12

Updated by zluo over 2 years 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.

Actions #13

Updated by zluo over 2 years 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
Actions #14

Updated by okurz over 2 years 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?

Actions #15

Updated by zluo over 2 years 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.

Actions #16

Updated by okurz over 2 years 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.

Actions #17

Updated by okurz over 2 years ago

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

Updated by szarate over 2 years ago

  • Status changed from In Progress to Rejected

Rejecting in favor of #109737

Actions #19

Updated by szarate over 2 years ago

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

Also available in: Atom PDF