Nightly failure: apiWebdavEtagPropagation1/moveFileFolder.feature:184

[saw-jan]

Build: https://drone.owncloud.com/owncloud/ocis/15819/53/6
Scenario: apiWebdavEtagPropagation1/moveFileFolder.feature:184
log:

Scenario Outline: as share receiver renaming a file inside a folder changes its etag for all collaborators    # /drone/src/oc10/testrunner/tests/acceptance/features/apiWebdavEtagPropagation1/moveFileFolder.feature:158
    Given user "Brian" has been created with default attributes and without skeleton files                      # FeatureContext::userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles()
    And the administrator has set the default folder for received shares to "Shares"                            # OccContext::theAdministratorHasSetTheDefaultFolderForReceivedSharesTo()
    And parameter "shareapi_auto_accept_share" of app "core" has been set to "no"                               # AppConfigurationContext::serverParameterHasBeenSetTo()
    And using <dav_version> DAV path                                                                            # FeatureContext::usingOldOrNewDavPath()
    And user "Alice" has created folder "/upload"                                                               # FeatureContext::userHasCreatedFolder()
    And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt"                    # FeatureContext::userHasUploadedAFileWithContentTo()
    And user "Alice" has shared folder "/upload" with user "Brian"                                              # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    And user "Brian" has accepted share "/upload" offered by user "Alice"                                       # FeatureContext::userHasReactedToShareOfferedBy()
    And user "Alice" has stored etag of element "/"                                                             # WebDavPropertiesContext::userHasStoredEtagOfElement()
    And user "Alice" has stored etag of element "/upload"                                                       # WebDavPropertiesContext::userHasStoredEtagOfElement()
    And user "Brian" has stored etag of element "/"                                                             # WebDavPropertiesContext::userHasStoredEtagOfElement()
    And user "Brian" has stored etag of element "/Shares"                                                       # WebDavPropertiesContext::userHasStoredEtagOfElement()
    And user "Brian" has stored etag of element "/Shares/upload"                                                # WebDavPropertiesContext::userHasStoredEtagOfElement()
    When user "Brian" moves file "/Shares/upload/file.txt" to "/Shares/upload/renamed.txt" using the WebDAV API # FeatureContext::userMovesFileUsingTheAPI()
    Then the HTTP status code should be "201"                                                                   # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And these etags should have changed:                                                                        # WebDavPropertiesContext::theseEtagsShouldHaveChanged()
      | user  | path           |
      | Alice | /              |
      | Alice | /upload        |
      | Brian | /              |
      | Brian | /Shares        |
      | Brian | /Shares/upload |

    Examples:
      | dav_version |
      | old         |
      | new         |
        WebDavPropertiesContext::theseEtagsShouldHaveChanged
        The etag '"b666b7b71d8250a78d7fc85d9ed81009"' of element '/upload' of user 'Alice' did not change.
        Failed asserting that 1 matches expected 0.

Related issues

#4251, #3988, #4091

[grgprarup]

This issue is similar to the issue #4091. The tests are skipped for OCIS owncloud/core#40225. @individual-it @kiranparajuli589 Can we skip these tests as discussed in the comment #4091 (comment)?

[grgprarup]

The issue is not reproducible locally and passing on recent nightly builds. Moving the issue to the backlog for now. We need to investigate if reoccurs.

[SwikritiT]

@grgprarup this issue hasn't been reproduced in a while now, will you be able to re-check it again the last time and close this issue if it's not reproduced now?

[individual-it]

please double-check if all etag tests are enabled in ocis and if yes close this issue

[grgprarup]

The issue is not reproducible locally and passing on recent nightly builds. Also, all etag tests are enabled in ocis and passing. So closing this issue.