search

owncloud / ocis

:atom_symbol: ownCloud Infinite Scale Stack
https://doc.owncloud.com/ocis/next/
Apache License 2.0
1.25k stars 169 forks source link

Flaky test on coreApiShareManagementToShares/moveReceivedShare.feature #9428

Closed amrita-shrestha closed 1 week ago

amrita-shrestha commented 1 week ago

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 commented 1 week ago

Failed builds:

saw-jan commented 1 week ago

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 commented 1 week ago

@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 commented 1 week ago

Reproducible on a low-spec machine

saw-jan commented 1 week ago

@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 https://github.com/owncloud/ocis/issues/9428#issuecomment-2182409013

saw-jan commented 1 week ago

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 commented 1 week ago

Scenarios that can be flaky due to the same reason: