Test apiWebdavMove1/moveFolder.feature:135 fails with 400 status

[phil-davis]

Describe the bug

  Scenario Outline: Moving a folder into a sub-folder of itself
    Given using <dav_version> DAV path
    And user "Alice" has created folder "PARENT"
    And user "Alice" has created folder "PARENT/CHILD"
    And user "Alice" has uploaded file with content "parent text" to "/PARENT/parent.txt"
    And user "Alice" has uploaded file with content "child text" to "/PARENT/CHILD/child.txt"
    When user "Alice" moves folder "/PARENT" to "/PARENT/CHILD/PARENT" using the WebDAV API
    Then the HTTP status code should be "409"
    And the content of file "/PARENT/parent.txt" for user "Alice" should be "parent text"
    And the content of file "/PARENT/CHILD/child.txt" for user "Alice" should be "child text"
    Examples:
      | dav_version |
      | old         |
      | new         |

Steps to reproduce

Steps to reproduce the behavior:

Run core API test apiWebdavMove1/moveFolder.feature:98

Expected behavior

Test passes.

Actual behavior

Test hangs. I think that the oCIS server-under-test goes int a loop and never responds.

After reva PR cs3org/reva#3009 the attempted move gives a 400 status. But oC10 gives a 409.
https://drone.cernbox.cern.ch/cs3org/reva/7783/17/6

 Scenario Outline: Moving a folder into a sub-folder of itself                               # /drone/src/tmp/testrunner/tests/acceptance/features/apiWebdavMove1/moveFolder.feature:135
    Given using <dav_version> DAV path                                                        # FeatureContext::usingOldOrNewDavPath()
    And user "Alice" has created folder "PARENT"                                              # FeatureContext::userHasCreatedFolder()
    And user "Alice" has created folder "PARENT/CHILD"                                        # FeatureContext::userHasCreatedFolder()
    And user "Alice" has uploaded file with content "parent text" to "/PARENT/parent.txt"     # FeatureContext::userHasUploadedAFileWithContentTo()
    And user "Alice" has uploaded file with content "child text" to "/PARENT/CHILD/child.txt" # FeatureContext::userHasUploadedAFileWithContentTo()
    When user "Alice" moves folder "/PARENT" to "/PARENT/CHILD/PARENT" using the WebDAV API   # FeatureContext::userMovesFileUsingTheAPI()
    Then the HTTP status code should be "409"                                                 # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And the content of file "/PARENT/parent.txt" for user "Alice" should be "parent text"     # FeatureContext::contentOfFileForUserShouldBe()
    And the content of file "/PARENT/CHILD/child.txt" for user "Alice" should be "child text" # FeatureContext::contentOfFileForUserShouldBe()

    Examples:
      | dav_version |
      | old         |
        HTTP status code 400 is not the expected value 409
        Failed asserting that 400 matches expected '409'.
      | new         |
        HTTP status code 400 is not the expected value 409
        Failed asserting that 400 matches expected '409'.
      | spaces      |
        HTTP status code 400 is not the expected value 409
        Failed asserting that 400 matches expected '409'.

Setup

Current oCIS master.

[phil-davis]

Examples:
https://drone.owncloud.com/owncloud/ocis/8916/30/6

https://drone.cernbox.cern.ch/cs3org/reva/5190/15/6

The problem seems to happen in cs3org/reva and in owncloud/ocis

[phil-davis]

See updated top post - the server no longer hsanages. Gives 400 status instead of expected 409.

https://drone.owncloud.com/owncloud/ocis/8916/30/3

The server output has lots of:

{"level":"error","service":"storage","pkg":"rgrpc","traceid":"00000000000000000000000000000000","error":"stat /srv/app/tmp/ocis/storage/users/nodes/d3c3c768-fe4b-48ea-bffe-dfebcbdd4c35: no such file or directory","id":"4854b876-c7c4-4077-9259-2eb07aeee835","time":"2022-01-24T08:40:53Z","message":"could not read node, skipping"}

And ends with:

"level":"error","service":"storage","pkg":"rgrpc","traceid":"00000000000000000000000000000000","error":"error: not found: b598f6cb-8188-40f2-a453-a743de13efde/PARENT","status":{"code":6,"message":"path not found when statting","trace":"00000000000000000000000000000000"},"reference":{"resource_id":{"storage_id":"d3dbfcb8-d04d-4f0f-9c2f-36f695ef3bb7","opaque_id":"d3dbfcb8-d04d-4f0f-9c2f-36f695ef3bb7"},"path":"./PARENT/CHILD/PARENT"},"time":"2022-01-24T08:40:53Z","message":"failed to stat"}

I suppose something goes "into a spin" after that, because there is no more log output, but the API request does not finish (the test runner is hung waiting for an API request to finish)

[phil-davis]

@micbar we thought that this was just a problem that caused an infinite loop when directly using CS3 APIs. But I get an infinite loop with this test scenario that uses webDAV and OCS APIs.

[phil-davis]

Note: when fixing this issue (presumably firstly in reva) please remove the skip of issue-ocis-3023 that had to be done in commit cs3org/reva@491579b of cs3org/reva master.

I will need to make a similar skip in cs3org/reva edge

And when pulling the fix into owncloud/ocis please do similar to remove the skip that was done in be9c804

If the skip is removed before the fix, then drone CI will go into the infinite loop. So the skips need to be removed along with the fix.

Edit update: cs3org/reva#3030 is removing the skip in reva edge branch.

[phil-davis]

Fixed in reva edge by cs3org/reva#3009 and cs3org/reva#3031

Should be fixed in oCIS when the latest reva is pulled in.

[phil-davis]

Latest reva was pulled in with PR #4076
PR #4109 re-enables the relevant test. This issue can be closed when that PR is merged.

[phil-davis]

The tests are still failing because of returning HTTP status 400 when it should be 409.
This needs reva PR cs3org/reva#3031 pulled into oCIS.