Web: list of intermittent fails and passes

Created on 7 Apr 2021  ·  23Comments  ·  Source: owncloud/web

Some web tests are failing intermittently in different PRs. We won't know if the failure should be investigated or not unless we realize how frequently the same test is failing. So, all the failures that were noticed are listed in this issue, to keep track of them.

Extension to https://github.com/owncloud/web/issues/4878

Fails

team
Source
picture Talank

Most helpful comment

@phil-davis All the fails in this list has been checked and made sure they don't fail anymore. I'm guessing it's safe to close this issue now?

picture SwikritiT on 29 Jun 2021
🎉2

All 23 comments

This issue is supposed to be fixed by PR https://github.com/owncloud/web/pull/4902 which was merged a few minutes ago. Let's wait and see if it fails again in other drone run. Not fixed yet

saw-jan picture saw-jan on 7 Apr 2021
kulmann picture kulmann on 7 Apr 2021

Cannot reproduce this in https://github.com/owncloud/web/pull/5335
https://drone.owncloud.com/owncloud/web/16724/6/21
https://drone.owncloud.com/owncloud/web/16718/6/21

saw-jan picture saw-jan on 8 Apr 2021

New Failure in

Edit: Seems to be fixed by: https://github.com/owncloud/web/pull/4930

jasson99 picture jasson99 on 8 Apr 2021

Intermittent unexpected pass:

jasson99 picture jasson99 on 15 Apr 2021
individual-it picture individual-it on 16 Apr 2021
kulmann picture kulmann on 16 Apr 2021

Recently many unexpected passes have been noticed after including core commit id in drone environment of the web. Need to investigate why those tests are passing in the drone.

Unexpected pass:

Talank picture Talank on 21 Apr 2021

@Talank those tests are not really unexpected passes but crashes of nightwatch CC @kiranparajuli589

individual-it picture individual-it on 22 Apr 2021
👍2

Recently many unexpected passes have been noticed after including core commit id in drone environment of the web. Need to investigate why those tests are passing in the drone.

Unexpected pass:
~- [ ] webUISharingNotificationsToRoot/shareWithUsers.feature:40~
~- https://drone.owncloud.com/owncloud/web/14921/11/14~
~- [ ] webUIPreview/imageMediaViewer.feature:83~
~- https://drone.owncloud.com/owncloud/web/14921/6/14~
~- [ ] webUIPreview/imageMediaViewer.feature:90~
~- https://drone.owncloud.com/owncloud/web/14921/6/14~
~- [ ] webUIPreview/imageMediaViewer.feature:140~
~- https://drone.owncloud.com/owncloud/web/14921/6/14~
~- [ ] webUIPreview/imageMediaViewer.feature:158~
~- https://drone.owncloud.com/owncloud/web/14921/6/14~
~- [ ] webUILogin/adminBlocksUser.feature:20~
~- https://drone.owncloud.com/owncloud/web/14921/6/14~

was noticed in drone run https://drone.owncloud.com/owncloud/web/14928/11/14 from PR https://github.com/owncloud/web/pull/4978. (actually was due to absence of notifications app on server, resolved now.)

kiranparajuli589 picture kiranparajuli589 on 22 Apr 2021
Talank picture Talank on 26 Apr 2021 
Failures:

1) Scenario: overwrite an existing file in a sub-folder (attempt 2) # tests/acceptance/features/webUIUpload/upload.feature:130
   ✔ Before # tests/acceptance/setup.js:30
   ✔ Before # tests/acceptance/setup.js:34
   ✔ Before # tests/acceptance/setup.js:38
   ✔ Before # tests/acceptance/setup.js:48
   ✔ Before # tests/acceptance/setup.js:69
   ✔ Before # tests/acceptance/setup.js:76
   ✔ Before # tests/acceptance/setup.js:87
   ✔ Before # tests/acceptance/stepDefinitions/filesContext.js:18
   ✔ Before # tests/acceptance/stepDefinitions/generalContext.js:248
   ✔ Before # tests/acceptance/stepDefinitions/generalContext.js:287
   ✔ Given user "Alice" has been created with default attributes and without skeleton files # tests/acceptance/stepDefinitions/provisioningContext.js:174
   ✔ And user "Alice" has created folder "simple-folder" # tests/acceptance/stepDefinitions/filesContext.js:903
   ✔ And user "Alice" has uploaded file with content "initial content" to "lorem.txt" # tests/acceptance/stepDefinitions/filesContext.js:95
   ✔ And user "Alice" has uploaded file with content "initial content" to "simple-folder/lorem.txt" # tests/acceptance/stepDefinitions/filesContext.js:95
   ✔ And user "Alice" has logged in using the webUI # tests/acceptance/stepDefinitions/loginContext.js:72
   ✔ When the user opens folder "simple-folder" using the webUI # tests/acceptance/stepDefinitions/filesContext.js:169
   ✔ And the user uploads overwriting file "lorem.txt" using the webUI # tests/acceptance/stepDefinitions/filesContext.js:1033
   ✔ Then file "lorem.txt" should be listed on the webUI # tests/acceptance/stepDefinitions/filesContext.js:399
   ✖ And as "Alice" the content of "simple-folder/lorem.txt" should be the same as the local "lorem.txt" # tests/acceptance/stepDefinitions/generalContext.js:132
       Error while running "strictEqual" command: Failed [strictEqual]: (asserting content of local file "/var/www/owncloud/web/tests/acceptance/filesForUpload/lorem.txt") - expected "initial content" but got: "Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium,
       totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae
       dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit,
       sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est
       qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora
       incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum
       exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur?" (0ms)
           at assertContentOfLocalFileIs (/var/www/owncloud/web/tests/acceptance/stepDefinitions/generalContext.js:156:24)
           at /var/www/owncloud/web/tests/acceptance/stepDefinitions/generalContext.js:140:19
           at runMicrotasks (<anonymous>)
           at processTicksAndRejections (internal/process/task_queues.js:97:5)
   ✔ After # tests/acceptance/stepDefinitions/provisioningContext.js:317
   ✔ After # tests/acceptance/stepDefinitions/generalContext.js:305
   ✔ After # tests/acceptance/stepDefinitions/generalContext.js:272
   ✔ After # tests/acceptance/setup.js:120
   ✔ After # tests/acceptance/setup.js:116
   ✔ After # tests/acceptance/setup.js:112
   ✔ After # tests/acceptance/setup.js:105
   ✔ After # tests/acceptance/setup.js:96
   ✔ After # tests/acceptance/setup.js:56
phil-davis picture phil-davis on 30 Apr 2021 
1) Scenario: cancel moving a file (attempt 2) # tests/acceptance/features/webUIMoveFilesFolders/moveFiles.feature:105
   ✔ Before # tests/acceptance/setup.js:30
   ✔ Before # tests/acceptance/setup.js:34
   ✔ Before # tests/acceptance/setup.js:38
   ✔ Before # tests/acceptance/setup.js:48
   ✔ Before # tests/acceptance/setup.js:69
   ✔ Before # tests/acceptance/setup.js:76
   ✔ Before # tests/acceptance/setup.js:87
   ✔ Before # tests/acceptance/stepDefinitions/filesContext.js:18
   ✔ Before # tests/acceptance/stepDefinitions/generalContext.js:248
   ✔ Before # tests/acceptance/stepDefinitions/generalContext.js:287
   ✔ Given user "Alice" has been created with default attributes and without skeleton files # tests/acceptance/stepDefinitions/provisioningContext.js:174
   ✔ And user "Alice" has created folder "simple-folder" # tests/acceptance/stepDefinitions/filesContext.js:903
   ✔ And user "Alice" has uploaded file "lorem.txt" to "lorem.txt" # tests/acceptance/stepDefinitions/filesContext.js:103
   ✔ Given user "Alice" has logged in using the webUI # tests/acceptance/stepDefinitions/loginContext.js:72
   ✔ And the user has browsed to the files page # tests/acceptance/stepDefinitions/filesContext.js:86
   ✔ When the user opens the file action menu of file "lorem.txt" using the webUI # tests/acceptance/stepDefinitions/filesContext.js:1256
   ✖ And the user selects move action for file "lorem.txt" using the webUI # tests/acceptance/stepDefinitions/filesContext.js:1198
       Timed out while waiting for element <//li[@id="app-sidebar-files-actions"]//button[@aria-label="Move"]> to be present for 20000 milliseconds. - expected "visible" but got: "not found" (20011ms)
           at Page.performFileAction (/var/www/owncloud/web/tests/acceptance/pageObjects/FilesPageElement/fileActionsMenu.js:43:10)
           at Page.move (/var/www/owncloud/web/tests/acceptance/pageObjects/FilesPageElement/fileActionsMenu.js:133:19)
           at _callee70$ (/var/www/owncloud/web/tests/acceptance/stepDefinitions/filesContext.js:1203:6)
           at asyncGeneratorStep (/var/www/owncloud/web/tests/acceptance/stepDefinitions/filesContext.js:75:103)
           at _next (/var/www/owncloud/web/tests/acceptance/stepDefinitions/filesContext.js:77:194)
           at /var/www/owncloud/web/tests/acceptance/stepDefinitions/filesContext.js:77:364
           at new Promise (<anonymous>)
           at World.<anonymous> (/var/www/owncloud/web/tests/acceptance/stepDefinitions/filesContext.js:77:97)
           at World.<anonymous> (/var/www/owncloud/web/tests/acceptance/stepDefinitions/filesContext.js:1198:5)
   - And the user selects the folder "simple-folder" as a place to move the file using the webUI # tests/acceptance/stepDefinitions/filesContext.js:1271
   - And the user cancels the attempt to move resources using the webUI # tests/acceptance/stepDefinitions/filesContext.js:1206
   - Then file "lorem.txt" should be listed on the webUI # tests/acceptance/stepDefinitions/filesContext.js:399
   - But file "lorem.txt" should not be listed in the folder "simple-folder" on the webUI # tests/acceptance/stepDefinitions/filesContext.js:612
   ✔ After # tests/acceptance/stepDefinitions/provisioningContext.js:317
   ✔ After # tests/acceptance/stepDefinitions/generalContext.js:305
   ✔ After # tests/acceptance/stepDefinitions/generalContext.js:272
   ✔ After # tests/acceptance/setup.js:120
   ✔ After # tests/acceptance/setup.js:116
   ✔ After # tests/acceptance/setup.js:112
   ✔ After # tests/acceptance/setup.js:105
   ✔ After # tests/acceptance/setup.js:96
   ✔ After # tests/acceptance/setup.js:56

I noticed this again in the nightly CI this morning (2021-05-11) https://drone.owncloud.com/owncloud/web/15374/15/14
And again (2021-05-14) https://drone.owncloud.com/owncloud/web/15453/15/14

phil-davis picture phil-davis on 4 May 2021
SwikritiT picture SwikritiT on 12 May 2021

@SwikritiT: I couldn't reproduce this error both locally and in CI. Maybe the problem has been fixed. So I'm marking it as done.

https://drone.owncloud.com/owncloud/web/16605/6/14
https://drone.owncloud.com/owncloud/web/16602

kulmann picture kulmann on 12 May 2021

On webUIOCISRename-chrome Fixed by : https://github.com/owncloud/web/pull/5120

and a similar intermittent fail:

dpakach picture dpakach on 18 May 2021

OCISSharingPublicDifferentRoles-chrome @SwikritiT https://github.com/owncloud/web/pull/5353

7) Scenario: creating a public link with "Uploader" role makes it possible to upload a folder (attempt 1, retried) # tests/acceptance/features/webUISharingPublicDifferentRoles/shareByPublicLinkDifferentRoles.feature:279 | 448s
-- | --
4125 | ✔ Before # tests/acceptance/setup.js:30 | 448s
4126 | ✔ Before # tests/acceptance/setup.js:34 | 448s
4127 | ✔ Before # tests/acceptance/setup.js:38 | 448s
4128 | ✔ Before # tests/acceptance/setup.js:48 | 448s
4129 | ✔ Before # tests/acceptance/setup.js:69 | 448s
4130 | ✔ Before # tests/acceptance/setup.js:76 | 448s
4131 | ✔ Before # tests/acceptance/setup.js:87 | 448s
4132 | ✔ Before # tests/acceptance/stepDefinitions/filesContext.js:18 | 448s
4133 | ✔ Before # tests/acceptance/stepDefinitions/generalContext.js:265 | 448s
4134 | ✔ Before # tests/acceptance/stepDefinitions/generalContext.js:304 | 448s
4135 | ✔ Given user "Alice" has been created with default attributes and without skeleton files # tests/acceptance/stepDefinitions/provisioningContext.js:174 | 448s
4136 | ✔ And user "Alice" has created folder "simple-folder" # tests/acceptance/stepDefinitions/filesContext.js:903 | 448s
4137 | ✔ Given user "Alice" has shared folder "simple-folder" with link with "create" permissions # tests/acceptance/stepDefinitions/sharingContext.js:511 | 448s
4138 | ✔ When the public uses the webUI to access the last public link created by user "Alice" # tests/acceptance/stepDefinitions/publicLinkContext.js:41 | 448s
4139 | ✔ And the public uploads file "FOLDER" in files-drop page # tests/acceptance/stepDefinitions/filesContext.js:244 | 448s
4140 | ✔ Then the following files should be listed on the files-drop page: # tests/acceptance/stepDefinitions/filesContext.js:254 | 448s
4141 | \| FOLDER \| | 448s
4142 | ✖ And as "Alice" file "simple-folder/FOLDER" should exist # tests/acceptance/stepDefinitions/webdavContext.js:74 | 448s
4143 | AssertionError [ERR_ASSERTION]: File should exist, but does not | 448s
4144 | + expected - actual | 448s
4146 | -404 | 448s
4147 | +207 | 448s
4148 | &nbsp; | 448s
4149 | at /var/www/owncloud/web/tests/acceptance/stepDefinitions/webdavContext.js:53:12 | 448s
4150 | at runMicrotasks (&lt;anonymous&gt;) | 448s
4151 | at processTicksAndRejections (internal/process/task_queues.js:97:5) | 448s
4152 | - And the content of file "simple-folder/FOLDER" for user "Alice" should be "" # tests/acceptance/stepDefinitions/filesContext.js:474 | 448s
4153 | ✔ After # tests/acceptance/stepDefinitions/provisioningContext.js:317 | 448s
4154 | ✔ After # tests/acceptance/stepDefinitions/generalContext.js:322 | 448s
4155 | ✔ After # tests/acceptance/stepDefinitions/generalContext.js:289 | 448s
4156 | ✔ After # tests/acceptance/stepDefinitions/generalContext.js:248 | 448s
4157 | ✔ After # tests/acceptance/setup.js:120 | 448s
4158 | ✔ After # tests/acceptance/setup.js:116 | 448s
4159 | ✔ After # tests/acceptance/setup.js:112 | 448s
4160 | ✔ After # tests/acceptance/setup.js:105 | 448s
4161 | ✔ After # tests/acceptance/setup.js:96 | 448s
4162 | ✔ After # tests/acceptance/setup.js:56
dpakach picture dpakach on 18 May 2021

Tests are failing in user login:

@SwikritiT : Couldn't reproduce this in https://github.com/owncloud/web/pull/5330
https://drone.owncloud.com/owncloud/web/16692/6/14

jasson99 picture jasson99 on 25 May 2021

I couldn't reproduce this error both locally and in CI. Maybe the problem has been fixed. So I'm marking it as done.

https://drone.owncloud.com/owncloud/web/16605/6/14
https://drone.owncloud.com/owncloud/web/16602/6/14

SwikritiT picture SwikritiT on 4 Jun 2021 

 tests/acceptance/features/webUITrashbinRestore/trashbinRestore.feature:14

    Given user "Alice" has been created with default attributes and without skeleton files
    And user "Alice" has created file "sample,1.txt"
    And user "Alice" has created folder "Folder,With,Comma"
    And user "Alice" has logged in using the webUI
√ Element <input[autocomplete="kopano-account username"]> was visible after 770 milliseconds.
√ Element <input[autocomplete="kopano-account username"]> was not present after 86 milliseconds.
√ Element <.oc-app-container> was visible after 828 milliseconds.
    Given user "Alice" has uploaded file "data.zip" to "data.zip"
    And the user has browsed to the files page
√ Element <//*[self::table[contains(@class, "files-table")] or self::div[contains(@class, "files-empty")] or self::div[contains(@class, "files-not-found")]]> was present after 128 milliseconds.
    When the user deletes file "data.zip" using the webUI
√ Element <//span[contains(@class, "oc-resource-name") and (@resource-name='data.zip' or @resource-path='/data.zip')]/ancestor::tr[contains(@class, "oc-tbody-tr")]> was present after 18 milliseconds.
√ Element <.files-table .oc-tbody-tr> was present after 16 milliseconds.
√ Element <//span[contains(@class, "oc-resource-name") and (@resource-name='data.zip' or @resource-path='/data.zip')]/ancestor::tr[contains(@class, "oc-tbody-tr")]//button[contains(@class, "oc-table-files-btn-show-details")]> was visible after 44 milliseconds.
√ Element <//li[@id="app-sidebar-files-actions"]//button[normalize-space()="Delete"]> was visible after 43 milliseconds.
√ Expected element <.oc-modal-body-actions-confirm> to be enabled in 20000ms (23ms)
√ Element <.oc-modal> was not present after 209 milliseconds.
    And the user deletes file "sample,1.txt" using the webUI
√ Element <//span[contains(@class, "oc-resource-name") and (@resource-name='sample,1.txt' or @resource-path='/sample,1.txt')]/ancestor::tr[contains(@class, "oc-tbody-tr")]> was present after 15 milliseconds.
√ Element <.files-table .oc-tbody-tr> was present after 9 milliseconds.
√ Element <//span[contains(@class, "oc-resource-name") and (@resource-name='sample,1.txt' or @resource-path='/sample,1.txt')]/ancestor::tr[contains(@class, "oc-tbody-tr")]//button[contains(@class, "oc-table-files-btn-show-details")]> was visible after 32 milliseconds.
√ Element <//li[@id="app-sidebar-files-actions"]//button[normalize-space()="Delete"]> was visible after 24 milliseconds.
√ Expected element <.oc-modal-body-actions-confirm> to be enabled in 20000ms (30ms)
√ Element <.oc-modal> was not present after 154 milliseconds.
    And the user browses to the trashbin page
√ Element <//*[self::table[contains(@class, "files-table")] or self::div[contains(@class, "files-empty")] or self::div[contains(@class, "files-not-found")]]> was present after 41 milliseconds.
    Then file "data.zip" should be listed on the webUI
√ Element <//span[contains(@class, "oc-resource-name") and (@resource-name='data.zip' or @resource-path='/data.zip') and @resource-type='file']/ancestor::tr[contains(@class, "oc-tbody-tr")]> was present after 14 milliseconds.
√ Element <.files-table .oc-tbody-tr> was present after 8 milliseconds.
    And file "sample,1.txt" should be listed on the webUI
√ Element <//span[contains(@class, "oc-resource-name") and (@resource-name='sample,1.txt' or @resource-path='/sample,1.txt') and @resource-type='file']/ancestor::tr[contains(@class, "oc-tbody-tr")]> was present after 15 milliseconds.
√ Element <.files-table .oc-tbody-tr> was present after 9 milliseconds.
    When the user restores file "data.zip" from the trashbin using the webUI
√ Element <//span[contains(@class, "oc-resource-name") and (@resource-name='data.zip' or @resource-path='/data.zip') and @resource-type='file']/ancestor::tr[contains(@class, "oc-tbody-tr")]> was visible after 24 milliseconds.
    ✖ failed
      Cannot read property 'trim' of null
      TypeError: Cannot read property 'trim' of null
          at NightwatchAPI.<anonymous> (/srv/app/web/tests/acceptance/pageObjects/FilesPageElement/filesList.js:326:43)
          at GetAttribute.complete (/srv/app/web/node_modules/nightwatch/lib/element/command.js:228:27)
          at successHandler (/srv/app/web/node_modules/nightwatch/lib/api/element-commands/_baseElementCommand.js:25:45)
          at PeriodicPromise.perform (/srv/app/web/node_modules/nightwatch/lib/utils/periodic-promise.js:105:29)
          at runMicrotasks (<anonymous>)
          at processTicksAndRejections (internal/process/task_queues.js:95:5)
          at PeriodicPromise.runAction (/srv/app/web/node_modules/nightwatch/lib/utils/periodic-promise.js:48:22)
          at PeriodicPromise.runAction (/srv/app/web/node_modules/nightwatch/lib/utils/periodic-promise.js:51:16)
    And the user restores file "sample,1.txt" from the trashbin using the webUI
    - skipped
    Then there should be no resources listed on the webUI
    - skipped
    When the user browses to the files page
    - skipped
    Then file "data.zip" should be listed on the webUI
    - skipped
    And file "sample,1.txt" should be listed on the webUI
    - skipped

The following logs were found in the browser console:

4:09:07 AM - SEVERE - https://ocis-server:9200/remote.php/dav/files/Alice/data.zip?a=1&c=eb15e46b886bac68404ef607a8e19eb6&preview=1&scalingup=0&x=1920&y=1920 - Failed to load resource: the server responded with a status of 404 (Not Found)
4:09:07 AM - SEVERE - https://ocis-server:9200/remote.php/dav/files/Alice/data.zip?a=1&c=eb15e46b886bac68404ef607a8e19eb6&preview=1&scalingup=0&x=1920&y=1920 - Failed to load resource: the server responded with a status of 404 (Not Found)

fixed in #5205

phil-davis picture phil-davis on 8 Jun 2021

@phil-davis what's the Definition of done for this issue? :)

pascalwengerter picture pascalwengerter on 15 Jun 2021

@Talank @kiranparajuli589 can you give a summary of where this is up to, and what is the chance that all the items will be sorted out "soon"?

Maybe we need to move items to their own issues. Because this issue becomes never-ending - some things are made reliable and then other intermittent tests are noticed.

phil-davis picture phil-davis on 15 Jun 2021

@phil-davis All the fails in this list has been checked and made sure they don't fail anymore. I'm guessing it's safe to close this issue now?

SwikritiT picture SwikritiT on 29 Jun 2021
🎉2
Was this page helpful?
0 / 5 - 0 ratings

Related issues

DeepDiver1975 picture DeepDiver1975  ·  6Comments
tomneedham picture tomneedham  ·  5Comments
ishank011 picture ishank011  ·  8Comments
DeepDiver1975 picture DeepDiver1975  ·  6Comments
tomneedham picture tomneedham  ·  3Comments