Flaky test on coreApiShareManagementToShares/moveReceivedShare.feature

[amrita-shrestha]

Describe the bug

Flaky tests
https://drone.owncloud.com/owncloud/ocis/36078/42/6

  Scenario: keep group share when the one user renames the share and the user is deleted      # /drone/src/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature:167
    Given group "grp1" has been created                                                       # FeatureContext::groupHasBeenCreated()
    And user "Brian" has been added to group "grp1"                                           # FeatureContext::userHasBeenAddedToGroup()
    And user "Carol" has been added to group "grp1"                                           # FeatureContext::userHasBeenAddedToGroup()
    And user "Alice" has created folder "/TMP"                                                # FeatureContext::userHasCreatedFolder()
    And user "Alice" has sent the following resource share invitation:                        # SharingNgContext::userHasSentTheFollowingResourceShareInvitation()
      | resource        | TMP      |
      | space           | Personal |
      | sharee          | grp1     |
      | shareType       | group    |
      | permissionsRole | Viewer   |
    When user "Carol" moves folder "/Shares/TMP" to "/Shares/new" using the WebDAV API        # FeatureContext::userMovesFileOrFolderUsingTheWebDavAPI()
    And the administrator deletes user "Carol" using the provisioning API                     # FeatureContext::theAdminDeletesUserUsingTheProvisioningApi()
    Then the HTTP status code of responses on each endpoint should be "201, 204" respectively # FeatureContext::theHTTPStatusCodeOfResponsesOnEachEndpointShouldBe()
      Expected HTTP status codes: "201, 204". Found HTTP status codes: "404,204"
      Failed asserting that false is true.
    And as "Alice" file "Shares/TMP" should not exist    

[saw-jan]

Failed builds:

• coreApiShareManagementToShares/moveReceivedShare.feature:172:

  • https://drone.owncloud.com/owncloud/ocis/36126/43/5
  • https://drone.owncloud.com/owncloud/ocis/36136/43/5
  • https://drone.owncloud.com/owncloud/ocis/36171/41/5
  • https://drone.owncloud.com/owncloud/ocis/36174/41/5
  • https://drone.owncloud.com/owncloud/ocis/36178/41/5
  • https://drone.owncloud.com/owncloud/ocis/36181/43/6
  • https://drone.owncloud.com/owncloud/ocis/36183/42/6
  • https://drone.owncloud.com/owncloud/ocis/36184/42/6
  • https://drone.owncloud.com/owncloud/ocis/36190/43/6
  • https://drone.owncloud.com/owncloud/ocis/36191/42/6
  • https://drone.owncloud.com/owncloud/ocis/36193/41/5
  • https://drone.owncloud.com/owncloud/ocis/36195/43/6
  • https://drone.owncloud.com/owncloud/ocis/36196/41/5
  • https://drone.owncloud.com/owncloud/ocis/36199/41/5
  • https://drone.owncloud.com/owncloud/ocis/36201/43/6
  • https://drone.owncloud.com/owncloud/ocis/36205/43/6
  • https://drone.owncloud.com/owncloud/ocis/36207/43/6

• coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:236:

  • https://drone.owncloud.com/owncloud/ocis/36180/43/6

[saw-jan]

First impressions: shares are not immediately available to the share receivers

But it's strange to see only in that particular test scenario

[amrita-shrestha]

@saw-jan PR related to this CI build has no changes related to this feature file but still fails. Maybe related to this issue
Build: https://drone.owncloud.com/owncloud/ocis/36208/43/5

Scenario: user included in multiple groups, shares a folder with a group                  # /drone/src/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:236
    Given these users have been created with default attributes and without skeleton files: # FeatureContext::theseUsersHaveBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles()
      | username |
      | Brian    |
    And group "grp1" has been created                                                       # FeatureContext::groupHasBeenCreated()
    And group "grp2" has been created                                                       # FeatureContext::groupHasBeenCreated()
    And user "Alice" has been added to group "grp1"                                         # FeatureContext::userHasBeenAddedToGroup()
    And user "Alice" has been added to group "grp2"                                         # FeatureContext::userHasBeenAddedToGroup()
    And user "Brian" has been added to group "grp1"                                         # FeatureContext::userHasBeenAddedToGroup()
    And user "Brian" has been added to group "grp2"                                         # FeatureContext::userHasBeenAddedToGroup()
    And user "Alice" has created folder "/PARENT"                                           # FeatureContext::userHasCreatedFolder()
    When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API       # FeatureContext::userSharesFileWithGroupUsingTheSharingApi()
    Then user "Brian" should see the following elements                                     # FeatureContext::userShouldSeeTheElements()
      | /Shares/PARENT/ |
      /remote.php/webdav/Shares/PARENT/ is not in propfind answer but should be

[saw-jan]

Reproducible on a low-spec machine

[saw-jan]

@saw-jan PR related to this CI build has no changes related to this feature file but still fails. Maybe related to this issue
Build: https://drone.owncloud.com/owncloud/ocis/36208/43/5

yes, the test failure is related to this and I have already added in the list above #9428 (comment)

[saw-jan]

First impressions: shares are not immediately available to the share receivers

But it's strange to see only in that particular test scenario

Can confirm that the shares weren't there while doing MOVE request.

[saw-jan]

Scenarios that can be flaky due to the same reason:

• need wait step https://drone.owncloud.com/owncloud/ocis/36229/28/6 ([tests-only][full-ci] wait and check for sync status before action #9491)
  • apiSpacesDavOperation/copyByFileId.feature:208
  • apiSharingNg/enableDisableShareSync.feature:151